我一直在一些人的工作中看到角色属性。我也在用,不知道效果如何。
例如:
<header id="header" role="banner">
Header stuff in here
</header>
或者:
<section id="facebook" role="contentinfo">
Facebook stuff in here
</section>
或者:
<section id="main" role="main">
Main content stuff in here
</section>
这个角色属性是必须的吗?
这个属性对语义更好吗?
它会改善SEO吗?
可以在 此处 找到角色列表,但我看到有些人是自己编的。是否允许或正确使用角色属性?
对此有什么想法吗?
原文由 jeroen 发布,翻译遵循 CC BY-SA 4.0 许可协议
您看到的大多数角色都被定义为 ARIA 1.0 的一部分,然后通过支持规范(如 HTML-AAM)合并到 HTML 中。一些新的 HTML5 元素(dialog、main 等)甚至基于原始的 ARIA 角色。
http://www.w3.org/TR/wai-aria/
Aria 的第一条规则 指出:
除了您的本机语义元素之外,还有一些使用角色的主要原因。
原因#1。 在没有合适的宿主语言元素或由于各种原因使用语义不太合适的元素的情况下覆盖角色。
在此示例中,使用了链接,尽管生成的功能比导航链接更像按钮。
屏幕阅读器用户会听到这是一个按钮(而不是链接),您可以使用 CSS 属性选择器来避免 class-itis 和 div-itis。
[7 年后的更新:删除了 * 选择器以使一些评论者高兴,因为在 2020 年不需要属性选择器上需要通用选择器的旧浏览器怪癖。]
原因#2。 备份原生元素的角色,以支持实现了 ARIA 角色但尚未实现原生元素角色的浏览器。
例如,“main”角色已在浏览器中得到支持多年,但它是 HTML5 中相对较新的添加,因此许多浏览器尚不支持
<main>
的语义。这在技术上是多余的,但可以帮助一些用户并且不会伤害任何用户。几年后,这种技术对于 main 可能变得不必要。
理由#3。 7 年后(2020 年)更新:正如至少一位评论者指出的那样,这现在对于自定义元素非常有用,并且正在进行一些规范工作来定义 Web 组件的默认可访问性角色。即使/一旦该 API 被标准化,也可能需要覆盖组件的默认角色。
备注/回复
你还写道:
除非不包括真正的角色,否则这是允许使用的属性。浏览器将应用令牌列表中第一个识别的角色。
在列表之外,只有
link
和note
是有效角色,因此链接角色将在平台可访问性 API 中应用,因为它首先出现。如果您使用自定义角色,请确保它们不会与 ARIA 中定义的任何角色或您使用的宿主语言(HTML、SVG、MathML 等)发生冲突