简答
如果您将菜单设置为模式对话框，则无需添加role="application"。对于其他模式，它可能适用（极不可能，role="application" 是一个非常专业的角色）但那时您可能首先实施了错误的模式。
更长的答案
只要正确实施，循环模式就很好（而且 target.com 做得很好）
只要正确实施，这种模式就没有什么问题（target.com 似乎出人意料地做得相当好，只是他们可以做得更好的几件事）。
以“目标”为例，您会注意到，当您单击“类别”时，显示的菜单实际上被视为模式对话框。
它有role="dialog"，打开它的“按钮”有aria-expanded。
如果您使用的是 tab 键，它们还会在此模式中捕获选项卡焦点并提供一个“关闭”按钮，该按钮显示在列表底部。
到目前为止一切都很好，在模态对话框中循环并没有错，因为这是预期的行为。
他们还做对了一些其他事情，一旦“对话框”打开，您将无法访问任何其他内容。例如，在屏幕阅读器中，您可以按 1-6 键来查找下一个标题级别，但您不能在菜单打开时执行此操作，因为它们会将 aria-hidden="true" 应用于菜单模式之外的所有内容（真正的模式陷阱）。
您还可以关闭菜单模式并将焦点返回到首先打开它的菜单项，因此它们也可以正确管理焦点。
最后，您可以使用 Escape 键关闭菜单模式，这也是预期的行为。
因此，如果您想在菜单中遵循这种模式，我会说去吧，它们可以按原样访问，并且屏幕阅读器用户不会费力地使用它们。
我们能比 target.com 做得更好
Target 的基础知识正确，只是缺少几个关键步骤。
打开菜单的“按钮”应该具有aria-controls 属性，以便正确地将它们链接在一起。
菜单对话框中的菜单项都应该在<ul> 周围有<nav> 元素（尽管可以说这些模态应该只能通过菜单按钮访问，这种关联是隐含的，这是一个小问题）。
他们使用的箭头精灵有focusable="false"，这很好，但他们没有添加role="presentation"，或者更好的是aria-hidden="true"，所以如果你的屏幕阅读器设置为详细，它们会被宣布。 （aria-hidden="true" 更好，因为支持更好）。
菜单本身不应该是多层的。即，如果您单击列表顶部的“主菜单”，那么您的位置就会变得混乱，我是否仍在模态对话框中？此外，这是以一种方式实现的，一旦您点击链接（可能是时间问题？），它就不会宣布“主菜单”列表中的第一项，因此它会让人迷失方向。这是他们的实现的最大问题。
还有其他东西，但你明白了，如果你的菜单只是每个“下拉”（模态）的一个列表，那么这种实现方式是完全可以接受和可用的，并且比我拥有的许多菜单实现更好见过。
所以我应该使用role="application"
没有。
说真的，你可能从不在你的职业生涯中需要使用它，而且它的使用会破坏很多可访问性。
哦，你想要更多细节吗？没问题！
不，您不需要在这里使用role="application"，实际上这样做会引入更多可访问性问题。
role="application" 表示所有控件都是自定义的，您应该忽略标准网站控件。 （您基本上是在告诉用户/屏幕阅读器“将其视为桌面应用程序，其中将通过菜单等解释快捷键”和“期望一些与网站无关的奇怪行为，不要依赖您的正常键盘快捷键因为他们可能不会工作'）
由于这遵循标准的网络模式（在模态中捕获焦点），因此添加 role="application" 实际上会使人们感到困惑。
您提到了 Tab 循环，但在列表中它按预期运行（按列表末尾的向下箭头不会循环），因此 Tab循环只发生在模态中。
我认为我在role="application" 上链接的页面的以下引用总结了重要信息。我添加了粗体以强调适用于您问题的关键点，并在适当的情况下添加了 cmets。
应用程序角色向辅助技术表明，这
部分网页内容包含不符合任何
其他已知的 HTML 元素或 WAI-ARIA 小部件。任何一种特殊的
应暂停对 HTML 结构和小部件的解释，并且
控制权应该完全交给浏览器和网络
处理鼠标、键盘或触摸交互的应用程序。
在这种模式下，网络作者全权负责处理
任何和所有键盘输入、焦点管理和其他交互
不能假设辅助技术会对
他们的结局。
所以基本上如果你添加了role="application"，你就不会得到任何元素的原生行为，这会引入很多工作！ （实际上大多数屏幕阅读器仍然允许基本功能，但他们这样做是因为人们滥用role="application"）
如果应用程序角色包含的网络应用程序包含
应该像普通网页内容一样对待的部分，一个角色
应使用文档或文章。
因此，您必须将role="article" 或role="document" 添加到列表、关闭按钮等。基本上整个事情都会有role="article"（因为那将是最合适的角色）。
除非您正在构建非常复杂的软件，否则不应使用role="application"。