键盘快捷键是否符合508合规性要求

Question

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

最大的问题是UI / UX设计师被告知下拉菜单NEEDS的键盘快捷键使键盘快捷键符合508标准。我看到Windows Forms应用程序有这个，但对于Web开发，我不认为这是必须的＆＃34;兼容＆＃34;

我回答的另一个问题是：MVC 4 site 508 compliant

Answer 1

某些标准（以及许多法律）的问题在于它们可以解释......

我在508标准中提到的唯一提及键盘使用is this（逐字）：

  

B部分 - 技术标准

     

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

     

（a）当软件被设计为在具有键盘的系统上运行时，产品功能应该可以从键盘执行   函数本身或执行函数的结果都可以   从文字上看。

我对此的看法是：

• 根据给定部分可能包含的操作/功能的数量，导航选项的键盘快捷方式可能不切实际。重要的是，它们可以通过键盘进行访问 -
• 从用户体验的角度来看，关键功能应该有“快捷方式”，因为它是良好的用户体验。但是要快捷所有从一个沟渠进入另一个沟渠。
• 508！=可访问性，但如果您为gov / edu工作，则可能是您的PD符合要求。

光谱的另一端是WCAG，它与508合规性相结合，在我的书中更好地定义：Keyboard stuff is under 'operable' in WCAG.

简而言之： 用户体验是一种很好的做法，可以为重要功能提供自定义键盘快捷键。但它本身与508合规无关。 （除了功能应该通过键盘 - 某些方式 - 可以访问）。

Answer 2

我部分同意瘦，但同意留下的评论的前两句话。

我指的是：

  

他们应该可以通过键盘来访问508.我一直强调快捷方式和可达之间的区别

Crixus说：

  

最大的问题是UI / UX设计师被告知下拉菜单NEEDS的键盘快捷键使键盘快捷键符合508标准。

你需要弄清楚这一点。您的意思是导航菜单的简单<select>或下拉菜单吗？正如Thinice在评论中所述，第508条只是说需要可以达到。问题变成：

  

如何您是否在应用程序中添加了快捷键？您是通过accesskeys属性添加它们还是Gmail / Yahoo Mail如何添加快捷键？

我以为我对AccessKeys做了一个答案，但找不到它。基本上，accesskeys听起来很棒，但是如果你看一下你可以使用的那些不会干扰浏览器或辅助技术键的键，你就会非常有限。 Gez Lemon做了an overview of AccessKeys, and their issues。如果你想要做Yahoo! Mail方法，你必须做更多的工作。 Todd Kloots提出presentation about ARIA，这可能会有所帮助。这引导我进入第二部分。如果您在网站上大量使用JavaScript来做事情，那么人们会使用 1194.21（软件应用程序/操作系统）和 1194.22（网络）标准来评估网站。如果站点使用JS创建navmenu（YUI menu example），则需要通过键盘访问下拉行为。我会说这属于：

  

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

和

  

（c）应提供明确定义的当前焦点的屏幕指示，当输入焦点改变时，该指示在交互式界面元素之间移动。重点应以程序化方式暴露，以便辅助技术可以跟踪焦点和焦点变化。

我说使用这两个标准是因为（a）说你必须能够通过键盘进入导航区域。 （c）进入游戏是因为某些菜单可以 tab 到所有父项，但是如果没有鼠标你就无法进入下拉部分。我看到菜单可以 tab 到子菜单项，但菜单没有弹出。因此，如果您只使用键盘（移动性障碍物），而不是使用JAWS，您将不知道自己身在何处。

  

我看到Windows Forms应用程序有这个，但是对于Web开发我不认为强制要求“合规”

我会说实际应用程序，如Word，Outlook等，提供常用命令的快捷方式。如果您正在为Web应用程序执行此操作，我会考虑您执行的操作数量。这不是强制性的要求。如果您正在制作导航栏，我建议您在父元素上使用ARIA roles，特别是role="navigation"作为最佳做法。

Answer 3

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

修改：屏幕阅读器会读取一些隐藏的元素。一种方法是将物品绝对定位在屏幕上方，具有负顶部位置。另一种方法是使用clip属性。 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

我会为“搜索”和“主页”等主要内容保存实际的访问权限。如果您拥有所有内容的accessKey，那么为您的网站添加学习曲线将无济于事。例如，如果您举例说明“关于我们”accessKey = A，并且您将20个accessKeys分配给字母，则会很糟糕。

我已经做了很长时间的508个网站，而且就个人而言，我只是不使用下拉菜单。添加子页面菜单要简单得多。我个人讨厌点击下拉列表。下拉菜单需要精确点击，这只会让我感到恼火，并且对辅助功能没有帮助，因为记住可访问性还包括不能很好地点击的人。此外，下拉菜单的级别数量有限，不是技术上的，而是来自UX视图。

我用的是什么：

• 标签索引。
• 仔细放置菜单，以便在听到网站或网页的基本概念之前，用户不会获得大量链接。
• 在某些项目中，顺序显示具有匹配箭头键页面导航的树状菜单。
• 如果需要，Accesskeys H为家庭，S为搜索，

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

运气。 ：）