aria role="application" 和 tab-trapping
aria role="application" and tab-trapping
Tab trapping is a fairly well established pattern (example)。通常为了可访问性，它允许键盘用户在下拉菜单和模式中导航。然而，令人担忧的是，现在选项卡事件的本机功能已被新行为（循环）覆盖，这对用户有何影响。这对有视力的用户来说不是什么大问题，但对于像 NVDA 和 JAWS 这样严重依赖原生标签功能的辅助技术用户来说，这是个问题。
WAI-ARIA 有一个解决方案，用于通知辅助技术何时以 aria-role="application" 的形式覆盖本机键盘功能：
Keyboard interaction is completely under the web author's control and
can be anything associated with the particular widget being
implemented. In a slides application, for example, a widget could be
created that uses the arrow keys to position elements on the slide,
and uses audio feedback via an ARIA live region to communicate the
position and overlap status with other objects. Focus is being managed
via aria-activedescendant.
The tab , Space and Enter keys, as well as Escape , must be handled by
the application. The one exception is if focus is set to a standard
widget inside the application that supports keyboard navigation from
the browser, for example an input element.
这意味着 任何使用制表符补漏的组件都应该有 role="application"、always.
但是我不相信这种普遍的做法。例如 Target.com 之类的网站（在下拉菜单中使用制表符补漏）将其归类为列表，如网站辅助功能树中所示：
如果有任何有经验的人对此提出意见，我将不胜感激。我在这里正确解释 ARIA 吗？使用制表符补漏的组件 always 是否应该用 role="application" 装饰？
简答
如果您将菜单设置为模态对话框，则无需添加 role="application"。对于其他模式，它可能适用（极不可能，role="application" 是一个非常专业的角色）但在这一点上，您可能首先实施了错误的模式。
更长的答案
只要正确实施，循环模式就很好（target.com 做得很好）
只要正确实施，这种模式就没有问题（target.com 似乎令人惊讶地做得很好，只是他们可以做得更好的几件事）。
以 'target' 为例，您会注意到当您单击 'categories' 时，显示的菜单实际上被视为模态对话框。
它有 role="dialog" 和打开它的 'button' 有 aria-expanded.
他们还在这个模式中捕获制表符焦点，并提供一个 'close' 按钮，如果您使用制表键，它会出现在列表的底部。
到目前为止一切正常，在模态对话框中循环没有任何问题，因为这是预期的行为。
他们还做对了一些其他事情，一旦 'dialog' 打开，您将无法访问任何其他内容。例如，在屏幕 reader 中，您可以按 1-6 键找到下一个标题级别，当菜单打开时您不能这样做，因为它们将 aria-hidden="true" 应用于菜单模式之外的所有内容（一个真正的模态陷阱）。
您也可以关闭菜单模式，焦点返回到首先打开它的菜单项，因此他们也可以正确管理焦点。
最后，您可以使用 Escape 键关闭菜单模式，这也是预期的行为。
因此，如果您想为您的菜单遵循这种模式，我会说去做吧，它们可以按原样访问，并且屏幕 reader 用户不会费力使用它们。
有什么比target.com
更好的了
Target 掌握了正确的基础知识，他们只是缺少几个关键步骤。
打开菜单的'button'应该有aria-controls属性才能link一起正常
菜单对话框中的菜单项都应该在 <ul> 周围有 <nav> 元素（尽管可以说这些模式只能通过菜单按钮访问，这种关联是隐含的，这是一个次要点）。
他们使用的箭头精灵有 focusable="false" 这很好，但他们没有添加 role="presentation" 或更好 aria-hidden="true" 所以如果你的屏幕 reader 设置为详细。 （aria-hidden="true" 更好，因为支持更好）。
菜单本身不应该是 multi-layered。即，如果您单击列表顶部的 'main menu'，它就会变得对您所在的位置感到困惑，我是否仍在模态对话框中？此外，这是以一种方式实现的，一旦您遵循 link（可能是时间问题？），它不会宣布 'main menu' 列表中的第一项，因此它会让人迷失方向。这是他们实施的最大问题。
还有其他事情，但你明白了，如果你的菜单只是每个 'drop down'（模态）的一个列表，这种实现方式是完全可以接受和可用的，并且比很多菜单更好我见过的实现。
所以我应该使用role="application"
没有
说真的，你可能 永远不会 在你的职业生涯中需要使用它，它的使用会破坏很多可访问性。
哦，你想要更多细节吗？没问题！
不，你不需要在这里使用 role="application"，事实上你会引入更多的可访问性问题。
role="application" 表示所有控件都是自定义的，您应该忽略标准网站控件。 （你基本上是在告诉用户/屏幕 reader 'treat this like a desktop application where shortcut keys will be explained via the menus etc.' 并且'期待一些与网站无关的奇怪行为，不要依赖你的普通键盘快捷键，因为它们可能不起作用'）
因为这遵循标准的 Web 模式（在模态中捕获焦点）添加 role="application" 实际上会使人感到困惑。
您提到了 Tab 循环，但在列表中它按预期运行（按列表末尾的向下箭头不会循环）所以 Tab 循环只发生在模式中。
我认为以下引用我 link 在 role="application" 上编辑的页面总结了重要信息。我添加了粗体以强调适用于您的问题的关键点，并在适当的后面添加了评论。
The application role indicates to assistive technologies that this
part of the web content contains elements that do not conform to any
other known HTML element or WAI-ARIA widget. Any sort of special
interpretation of HTML structures and widgets should be suspended, and
control should be completely handed over to the browser and web
application to handle mouse, keyboard, or touch interaction.
In this mode, the web author is completely responsible for handling
any and all keyboard input, focus management, and other interactions
and cannot assume assistive technologies would do any processing on
their end.
所以基本上，如果您添加 role="application"，您将无法获得任何元素的本机行为，这会引入大量工作！ （在实践中，大多数屏幕 readers 仍将允许基本功能，但他们这样做是因为人们滥用 role="application"）
If the web application encompassed by the application role contains
parts that should be treated like normal web content, a role of
document or article should be used.
因此您必须将 role="article" 或 role="document" 添加到列表、关闭按钮等。基本上整个事情都会 hae role="article" 无论如何（因为那将是最合适的角色）。
除非您正在构建非常复杂的软件，否则不应使用 role="application"。
Tab trapping is a fairly well established pattern (example)。通常为了可访问性，它允许键盘用户在下拉菜单和模式中导航。然而，令人担忧的是，现在选项卡事件的本机功能已被新行为（循环）覆盖，这对用户有何影响。这对有视力的用户来说不是什么大问题，但对于像 NVDA 和 JAWS 这样严重依赖原生标签功能的辅助技术用户来说，这是个问题。
WAI-ARIA 有一个解决方案，用于通知辅助技术何时以 aria-role="application" 的形式覆盖本机键盘功能：
Keyboard interaction is completely under the web author's control and can be anything associated with the particular widget being implemented. In a slides application, for example, a widget could be created that uses the arrow keys to position elements on the slide, and uses audio feedback via an ARIA live region to communicate the position and overlap status with other objects. Focus is being managed via aria-activedescendant.
The tab , Space and Enter keys, as well as Escape , must be handled by the application. The one exception is if focus is set to a standard widget inside the application that supports keyboard navigation from the browser, for example an input element.
这意味着 任何使用制表符补漏的组件都应该有 role="application"、always.
但是我不相信这种普遍的做法。例如 Target.com 之类的网站（在下拉菜单中使用制表符补漏）将其归类为列表，如网站辅助功能树中所示：
如果有任何有经验的人对此提出意见，我将不胜感激。我在这里正确解释 ARIA 吗？使用制表符补漏的组件 always 是否应该用 role="application" 装饰？
简答
如果您将菜单设置为模态对话框，则无需添加 role="application"。对于其他模式，它可能适用（极不可能，role="application" 是一个非常专业的角色）但在这一点上，您可能首先实施了错误的模式。
更长的答案
只要正确实施，循环模式就很好（target.com 做得很好）
只要正确实施，这种模式就没有问题（target.com 似乎令人惊讶地做得很好，只是他们可以做得更好的几件事）。
以 'target' 为例，您会注意到当您单击 'categories' 时，显示的菜单实际上被视为模态对话框。
它有 role="dialog" 和打开它的 'button' 有 aria-expanded.
他们还在这个模式中捕获制表符焦点，并提供一个 'close' 按钮，如果您使用制表键，它会出现在列表的底部。
到目前为止一切正常，在模态对话框中循环没有任何问题，因为这是预期的行为。
他们还做对了一些其他事情，一旦 'dialog' 打开，您将无法访问任何其他内容。例如，在屏幕 reader 中，您可以按 1-6 键找到下一个标题级别，当菜单打开时您不能这样做，因为它们将 aria-hidden="true" 应用于菜单模式之外的所有内容（一个真正的模态陷阱）。
您也可以关闭菜单模式，焦点返回到首先打开它的菜单项，因此他们也可以正确管理焦点。
最后，您可以使用 Escape 键关闭菜单模式，这也是预期的行为。
因此，如果您想为您的菜单遵循这种模式，我会说去做吧，它们可以按原样访问，并且屏幕 reader 用户不会费力使用它们。
有什么比target.com
更好的了Target 掌握了正确的基础知识，他们只是缺少几个关键步骤。
打开菜单的'button'应该有aria-controls属性才能link一起正常
菜单对话框中的菜单项都应该在 <ul> 周围有 <nav> 元素（尽管可以说这些模式只能通过菜单按钮访问，这种关联是隐含的，这是一个次要点）。
他们使用的箭头精灵有 focusable="false" 这很好，但他们没有添加 role="presentation" 或更好 aria-hidden="true" 所以如果你的屏幕 reader 设置为详细。 （aria-hidden="true" 更好，因为支持更好）。
菜单本身不应该是 multi-layered。即，如果您单击列表顶部的 'main menu'，它就会变得对您所在的位置感到困惑，我是否仍在模态对话框中？此外，这是以一种方式实现的，一旦您遵循 link（可能是时间问题？），它不会宣布 'main menu' 列表中的第一项，因此它会让人迷失方向。这是他们实施的最大问题。
还有其他事情，但你明白了，如果你的菜单只是每个 'drop down'（模态）的一个列表，这种实现方式是完全可以接受和可用的，并且比很多菜单更好我见过的实现。
所以我应该使用role="application"
没有
说真的，你可能 永远不会 在你的职业生涯中需要使用它，它的使用会破坏很多可访问性。
哦，你想要更多细节吗？没问题！
不，你不需要在这里使用 role="application"，事实上你会引入更多的可访问性问题。
role="application" 表示所有控件都是自定义的，您应该忽略标准网站控件。 （你基本上是在告诉用户/屏幕 reader 'treat this like a desktop application where shortcut keys will be explained via the menus etc.' 并且'期待一些与网站无关的奇怪行为，不要依赖你的普通键盘快捷键，因为它们可能不起作用'）
因为这遵循标准的 Web 模式（在模态中捕获焦点）添加 role="application" 实际上会使人感到困惑。
您提到了 Tab 循环，但在列表中它按预期运行（按列表末尾的向下箭头不会循环）所以 Tab 循环只发生在模式中。
我认为以下引用我 link 在 role="application" 上编辑的页面总结了重要信息。我添加了粗体以强调适用于您的问题的关键点，并在适当的后面添加了评论。
The application role indicates to assistive technologies that this part of the web content contains elements that do not conform to any other known HTML element or WAI-ARIA widget. Any sort of special interpretation of HTML structures and widgets should be suspended, and control should be completely handed over to the browser and web application to handle mouse, keyboard, or touch interaction.
In this mode, the web author is completely responsible for handling any and all keyboard input, focus management, and other interactions and cannot assume assistive technologies would do any processing on their end.
所以基本上，如果您添加 role="application"，您将无法获得任何元素的本机行为，这会引入大量工作！ （在实践中，大多数屏幕 readers 仍将允许基本功能，但他们这样做是因为人们滥用 role="application"）
If the web application encompassed by the application role contains parts that should be treated like normal web content, a role of document or article should be used.
因此您必须将 role="article" 或 role="document" 添加到列表、关闭按钮等。基本上整个事情都会 hae role="article" 无论如何（因为那将是最合适的角色）。
除非您正在构建非常复杂的软件，否则不应使用 role="application"。