11

我对此进行了很多研究，似乎在 SO 和所有网络上都得到了相互矛盾的答案。我明白，对于第 508 节，合规性不等于可访问性。

最重要的是，UI/UX 设计师被告知下拉菜单的键盘快捷键需要具有符合 508 的键盘快捷键。我看到 Windows 窗体应用程序具有此功能，但对于 Web 开发，我认为“合规”不是强制性的

我回答的另一个问题在这里：MVC 4 site 508 compliant

4

3 回答 3

5

一些标准（以及许多法律）的问题在于它们对解释持开放态度......

我在 508 标准中唯一提到键盘使用的是这个（逐字）：

B分部——技术标准

§ 1194.21 软件应用程序和操作系统。

(a) 当软件设计为在具有键盘的系统上运行时，产品功能应可从键盘执行，其中功能本身或执行功能的结果可通过文本识别。

我对此的看法是：

  • 考虑到给定部分可能包含的操作/功能的数量，导航选项的键盘快捷键可能不切实际。重要的是它们可以通过键盘以某种方式访问​​。
  • 从用户体验的角度来看，关键特性应该有快捷方式，“仅仅因为”它是良好的用户体验实践。但是为了走捷径，一切都会从一个沟渠进入另一个沟渠。
  • 508 != 可访问性，但如果您为 gov/edu 工作，那么您的 PD 很可能符合要求。

频谱的另一端是 WCAG，它与 508 合规性几乎相结合，在我的书中得到了更好的定义：键盘的东西在 WCAG 中是“可操作的”。

简而言之：对于用户体验来说，为重要功能提供自定义键盘快捷键是一种很好的做法。但本身与 508 合规性无关。（除了功能应该可以通过键盘访问 - 不知何故 - ）。

于 2012-07-28T05:13:50.323 回答
5

我部分同意thinice，但同意评论的前两句话。

我指的句子是：

对于 508，它们应该可以通过键盘访问。我一直强调快捷方式和可访问之间的区别

Crixus 说：

最重要的是，UI/UX 设计师被告知下拉菜单的键盘快捷键需要具有符合 508 的键盘快捷键。

你需要澄清这一点。您是指<select>导航菜单的简单菜单还是下拉菜单？正如 Thinice 在评论中所说，第 508 条只是说需要可达。问题变成：

你是如何为你的应用程序添加快捷键的？您是通过 accesskeys 属性添加它们还是 Gmail/Yahoo Mail 如何添加快捷键？

我以为我回答了有关 AccessKeys 的问题，但找不到。从本质上讲，accesskeys 听起来很棒，但是如果您查看允许使用的密钥，它们不会干扰浏览器或辅助技术密钥，那么您的能力就非常有限。Gez Lemon对 AccessKeys 及其问题进行了概述。如果你想使用 Yahoo!Mail 方法，你必须做更多的工作。Todd Kloots 做了一个关于 ARIA 的演讲，这可能会有所帮助。这使我进入第二部分。如果您在网站上大量使用 JavaScript 来做事，人们会同时使用1194.21（软件应用程序/操作系统）和1194.22（网络）标准来评估网站。如果网站使用JS制作navmenu（YUI菜单示例)，下拉行为需要可以通过键盘访问。我会说这属于：

§ 1194.21 软件应用程序和操作系统。
(a) 当软件设计为在具有键盘的系统上运行时，产品功能应可从键盘执行，其中功能本身或执行功能的结果可通过文本识别。

和

(c) 应提供明确定义的当前焦点屏幕指示，随着输入焦点的变化在交互界面元素之间移动。焦点应以编程方式公开，以便辅助技术可以跟踪焦点和焦点变化。

我说这两个标准都被使用了，因为 (a) 说你必须能够通过键盘进入导航区域。(c) 之所以起作用，是因为您可以使用某些菜单tab访问所有父项，但如果没有鼠标则无法进入下拉部分。我见过的菜单，你可以tab到子菜单项，但菜单不弹出打开。因此，如果您只使用键盘（移动设备），而不是使用 JAWS，您将不知道自己在哪里。

我看到 Windows 窗体应用程序具有此功能，但对于 Web 开发，我认为“合规”不是强制性的

我会说实际的应用程序，如 Word、Outlook 等，提供常用命令的快捷方式。如果您是为 Web 应用程序执行此操作，我会考虑您做了多少。这不是必须遵守的。如果您正在制作导航栏，我建议您使用ARIA 角色，特别role="navigation"是在父元素上作为最佳实践。

于 2012-07-29T21:04:06.603 回答
1

如果您谈论的是政府项目，则存在 508 合规级别。一些部门为他们的开发人员分配了 508 分，它会影响你未来合同的分数。508 合规性只要求所有内容都可以通过键盘访问，这在某种程度上通常是正确的。屏幕阅读器将阅读所有未隐藏的内容，并且 Tab 键将引导人们浏览链接。但如果你想要一个好分数，你必须解决意图，而不仅仅是法律条文。

编辑：屏幕阅读器将阅读一些隐藏的元素。一种方法是将项目绝对定位在屏幕上方，顶部位置为负。另一种是使用剪辑属性。 http://adaptivethemes.com/using-css-clip-as-an-accessible-method-of-hiding-content/ 但是如果你使用 display:none、零高度和 javascript 切换，许多屏幕阅读器会不讲这些项目。

在下拉的情况下，您正在积极地向屏幕阅读器等隐藏元素，因此您必须修复它，因为大多数阅读器不会听到 display:none 的内容。

您将找不到有关键盘导航的权威文档。没有人确切说明要做什么的原因是，有很多潜在的冲突——与浏览器、操作系统等。也没有标准，尽管 Aria 正在取得进展： http ://www.w3.org /TR/wai-aria-practices/#keyboard

如果这就是您的意思，我不会将 accessKeys 放在菜单上。
而是参见：http ://www.w3.org/TR/wai-aria-practices/#aria_ex_widget

我会为“搜索”和“主页”等主要内容保存实际的访问密钥。如果您拥有所有内容的访问密钥，则向您的站点添加学习曲线将无济于事。例如，如果您输入“About Us”accessKey=A，并且您有 20 个 accessKeys 分配给字母，那就不好了。

我做 508 网站已经很久了，就我个人而言，我只是不使用下拉菜单。添加子页面菜单要简单得多。我个人讨厌点击下拉菜单。下拉菜单需要精确的点击，这只会让我感到恼火，并且对可访问性没有帮助，因为记住可访问性还包括点击不佳的人。另外，下拉菜单在您可以拥有的级别数量上是有限的，这不是技术上的，而是从用户体验角度来看的。

我用什么：

  • 标签索引。
  • 精心布置的菜单，以便用户在听到网站或页面的基本概念之前不会获得大量链接列表。
  • 在某些项目中，具有匹配箭头键页面导航的树形菜单按顺序排列。
  • 如果需要，访问键 H 用于主页，S 用于搜索。

问题尤其是在排序信息方面。想想你扫描一长串链接的速度有多快，然后想象坐在那里等待它被读给你听。也许，将您的内容组织成易于理解的部分并让搜索框进行扫描。取决于内容。

运气。:)

于 2012-07-31T08:50:36.247 回答