我进行了大量的研究，在SO和整个网络上似乎得到了相互矛盾的答案。我知道，符合Section 508规范并不等同于可访问性。
最重要的是，UI/UX设计师被告知下拉菜单的键盘快捷键需要有键盘快捷键才能符合508规范。我看到Windows Forms应用程序有这个功能，但对于Web开发来说，我认为这并非“规范”所必须的。
我的另一个问题在这里得到了回答：MVC 4网站是否符合508规范
3个回答
5
一些标准（以及许多法律）的问题在于它们可以被解释... 我能在508标准中找到唯一提到键盘使用的提法在这里（原话）：
引用： 子部分B--技术标准 § 1194.21软件应用和操作系统。 (a)当软件设计为在具有键盘的系统上运行时，产品功能应该可以从键盘执行，其中功能本身或执行功能的结果可以以文本形式辨别。
我的理解是：
引用： 子部分B--技术标准 § 1194.21软件应用和操作系统。 (a)当软件设计为在具有键盘的系统上运行时，产品功能应该可以从键盘执行，其中功能本身或执行功能的结果可以以文本形式辨别。
我的理解是：
- 考虑到某个部分可能包含的操作/功能数量，导航选项的键盘快捷方式可能不切实际。重要的是，它们可以通过键盘“某种方式”到达。
- 从用户体验的角度来看，关键特性应该有快捷方式，因为这是良好的用户体验实践。但是将所有东西都设为快捷方式就会走向另一个极端。
- 508并非无障碍，但如果您为政府/教育工作，则遵守规定可能属于您的职责范畴。
- thinice
2
你认为下拉菜单需要有键盘快捷键才能符合508合规要求，从而适合向要求508合规的政府或国家机构销售吗？是否应该为使用JAWS阅读器等辅助工具的人使用网站的简化版本？ - Tom Stickel
它们应该能够通过键盘实现508可达性。我强调快捷方式和可达性之间的区别。您是否能提供简单版本或RDF数据取决于您拥有的资源类型以及项目设置方式。 - thinice
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（Web）标准来评估网站。如果网站使用JS制作导航菜单（YUI菜单示例），则下拉行为需要通过键盘访问。我会说这属于：
§ 1194.21软件应用程序和操作系统。
（a）当软件被设计为在具有键盘的系统上运行时，产品功能应该可以从键盘执行，其中功能本身或执行功能的结果可以以文本形式辨别。
和
我认为两种标准都被使用是因为（a）规定必须能够通过键盘进入导航区域。 （c）适用于某些菜单，您可以通过tab访问所有父项，但无法在没有鼠标的情况下进入下拉部分。我见过一些菜单，您可以tab到子菜单项，但菜单不会弹出。因此，如果您只使用键盘（移动障碍），而不使用JAWS，您将不知道自己在哪里。（c）提供当前焦点的明确定义的屏幕指示，该焦点随着输入焦点的更改而在交互式界面元素之间移动。焦点应该以编程方式公开，以便辅助技术可以跟踪焦点和焦点更改。
我认为实际应用程序，如Word，Outlook等，提供经常使用命令的快捷方式。如果您正在为Web应用程序做这件事，则需要考虑您要做多少。这不是强制性的合规要求。如果您正在创建像导航栏之类的内容，则建议在父元素上使用ARIA角色，特别是我看到Windows Forms应用程序有这个功能，但对于Web开发来说，我认为这不是“合规”的必要条件
role="navigation"作为最佳实践。- Ryan B
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
我会将实际的 accessKeys 保存用于像“搜索”和“主页”之类的重要事项。如果您为每个东西都设置 accessKey，则会增加网站的学习曲线。例如，如果您将“关于我们”的 accessKey 设置为 A，并且您已分配了 20 个 accessKeys 给字母，则会很糟糕。
我已经做了很长时间的508网站，个人而言，我不使用下拉菜单。添加子页面菜单要简单得多。我个人讨厌点击下拉菜单。下拉菜单需要精确的点击，这让我感到烦恼，并且对可访问性没有帮助，因为请记住，可访问性还包括那些不太会点击的人。此外，从用户体验的角度来看，下拉菜单在可以拥有的级别数量上是有限制的，虽然技术上并非如此。我的做法：
- Tab索引。 - 仔细放置菜单，以便用户在听到站点或页面的基本概念之前不会看到大量链接列表。 - 在某些项目中，使用树形菜单和匹配的箭头键页面导航，按顺序进行。 - 如果需要，使用H键回到主页和S键搜索Accesskeys。
问题尤其在于信息的排序。想象一下您快速浏览长列表的链接的速度，然后想象坐在那里等待它被读出来。也许，将您的内容组织成易于消化的部分，并让搜索框进行扫描。这取决于内容。
祝好运。 :)
- Jen
3
抱歉Jennifer，你给出的建议并不是最好的。“屏幕阅读器将会读取所有未隐藏的内容” - 实际上，有些阅读器会读取它，这取决于它被如何隐藏。AccessKeys可以使用，但范围有限 - 如果您想使用它们，我建议使用英国的标准。您列出了使用tabindex，但没有提供任何其他信息。真正应该使用的唯一值是0或-1。超出这个范围，您可能会给自己、开发人员或最终用户带来麻烦。 - Ryan B
给Ryan，如果你觉得这篇文章有误导性，你可以进行编辑。但我也希望你能考虑一下，缺乏有用信息的原因是否部分是因为没有人被允许在不受这种反应的情况下发言。请不要对此持消极态度，每当我试图帮助别人解决这个问题时，这种情况总是发生。我将编辑我所说的“隐藏”内容。 - Jen
2我没有编辑它，因为编辑会改变你回答的语气。比如，你提倡使用选项卡索引。但是如果OP只在导航上打上1-6，一些浏览器/AT将在第七个选项卡按键时将用户发送回URL栏。 “没有人可以不经过这种反应就说话。”，你能解释一下吗？我的反应是因为你只是扔出了关键词，几乎没有解释。如果你知道这个主题，花两分钟时间教教那个人，而不是简单地回答问题。 - Ryan B
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接