使用WAI ARIA的实际效果？ [英] Actual effect of using WAI ARIA?

问题描述

我正在尝试深入研究ARIA并使我的网站更容易访问。
我理解使用ARIA属性是一个好的开始，但我想了解这样做的实际效果。

I'm trying to dig into ARIA and make my websites more accessible. I understood using ARIA attributes is a good start but I'd like to understand the actual effects of doing so.

例如，如果我添加一个我的导航标签上的role =navigation用作菜单，这对用户有什么影响？

If, for instance, I add a role="navigation" on my nav tag used as a menu, what effect will this have for the user?

它的屏幕阅读器（或任何帮助他的应用程序）会做什么？ ？
如果我已经使用了导航标签，那么添加它真的很有用吗，显然已经告诉用户这是导航项了吗？

What will its screenreader (or any app helping him) do? Is it really useful to add this if I'm already using a nav tag, which obviously is already telling the user that this is a navigation item?

谢谢！

推荐答案

我理解的方式是添加ARIA角色将在您的网站上创建语义分类（称为地标）用户可以导航到使用由ARIA支持的屏幕阅读器定义的键盘快捷键（键绑定）。

The way I understand it is that adding ARIA roles will create a taxonomy of semantics (called landmarks) on your site that a user can navigate to using keyboard shortcuts (key bindings) defined by screen readers with ARIA support.

例如，不要跳过按钮/链接等可操作元素，用户可以使用不同的键绑定来跳转到ARIA地标。

For example, instead of jumping through actionable elements like buttons/links, the user can use a different key binding to jump to ARIA landmarks instead.

默认情况下，屏幕阅读器客户端应该处理诸如nav之类的语义标签（并且具有这样做的特定键绑定 - 通常是tab）。 ARIA角色 - 在这种情况下 - 只需添加另一级语义，并通过扩展，另一种方法来浏览页面。

Semantic tags such as "nav" should be handled by the screen reader client by default (and have a specific key binding to do so - usually "tab"). ARIA roles - in this scenario - just add another level of semantics and, by extension, an alternate method for navigating through the page.

A 链接到WAI-ARIA角色模型W3C规范。

这篇关于使用WAI ARIA的实际效果？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！