【问题标题】:Is it semantically correct to use <h1> in a dialog?在对话框中使用 <h1> 在语义上是否正确?
【发布时间】:2016-11-21 18:35:44
【问题描述】:

我浏览了The Incredible Accesible Dialog v3 的代码,我注意到他们使用的是&lt;h1&gt; 标签

<div id="modal" aria-hidden="false" aria-labelledby="modalTitle" aria-describedby="modalDescription" role="dialog">
    <div id="modalDescription" class="screen-reader-offscreen">...</div>
    <h1 id="modalTitle">...</h1>
    <p>...</p>
    <form name="form1" onsubmit="return false;">...</form>
</div>

这让我开始思考,这在语义上真的正确吗?我的意思是每个人都在说文档中应该只有 1 个&lt;h1&gt;

请注意,在以前版本的对话框中,他们为对话框提供了 role="document",这使得使用 &lt;h1&gt; ok imho

【问题讨论】:

    标签: html dialog accessibility wai-aria


    【解决方案1】:

    我知道你已经接受了一个答案,但它并不完全正确。

    当然,您可以在对话框中输入&lt;h1&gt;,这样就不会着火了。然而,这在技术上是不正确的。

    标题级别应该代表它在页面结构中的位置。如果您的页面只有一个&lt;h1&gt;,这是您最好的选择,那么对话框应该获得一个与其在页面结构中的位置(其内容)相对应的标题级别。

    很可能该对话框不适合其余内容的流程,因此它应该是页面&lt;h1&gt; 的子集(因为它是关于页面的对话框),从而使对话框采用@987654334 @。

    如果您使用选项卡式界面,并且您已将选项卡构建为每个&lt;h2&gt;s,并且您的对话框适用于特定选项卡,那么您的对话框将采用&lt;h3&gt;

    等等。

    添加role=document 不会改变这一点(和may be a mis-application of the document ARIA role 除非您明确使用辅助技术进行测试以确保它按预期工作)。

    你可以看到all-&lt;h1&gt; model is now considered an anti-pattern in HTML 5.1W3C HTML validator 现在将标记它。

    您可以在由 HTML5 规范的一位编辑撰写的文章中阅读有关构造标题方法的更多信息:Computer says NO to HTML5 document outline

    因此,要回答您最初的问题,不,在对话中使用 &lt;h1&gt; 在语义上是不正确的。

    【讨论】:

    • 虽然我同意你的观点,但有趣的是在规范中没有提到这个“规则”。我什至在发布这个问题之前检查过。是的,我正在查看的对话框(The Incredible Accesible Dialog)实际上已经使用许多屏幕阅读器(列在底部)进行了测试,因此他们不会轻易使用 ARIA 角色。
    • 1.该规范确实提到了&lt;h1&gt;“规则”,并有had a warning since HTML5.0open bugs 来修复它。 2. 见blog post about the dialog: "removed the role=”document” from the content of the window。这最初是为了处理 NVDA 与 role=”dialog” 交互的方式而插入的,但该问题已在 NVDA 中得到解决。”
    • 截至 2020 年 10 月,“§ 4.3.3 节元素”中的第一个示例指出:“注意如何使用节意味着作者可以自始至终使用 h1 元素,而不必担心特定部分是否处于顶级、第二级、第三级等等。”见:html.spec.whatwg.org/multipage/…
    • 考虑到它还列出了&lt;hgroup&gt;(没有支持)并依赖于从未实现的文档大纲算法,这令人难以置信。因此,如果您支持用户,请忽略规范的那部分。如果您的目标是代码合规性,那就发疯。参考:adrianroselli.com/2016/08/…,codepen.io/stevef/post/a-decade-of-heading-backwards
    【解决方案2】:

    从语义上讲,您可以使用h1 开始文档的任何新部分(部分、文章、导航、旁边、页眉、页脚)。

    它会随着 HTML 5.1 改变,但 h1 可能仍用于 dialog (*) 元素,因为它们被视为“分节根”。见http://w3.org/TR/html51/sections.html#headings-and-sections)。

    某些元素被称为分节根,包括 blockquote 和 td 元素。这些元素可以有自己的轮廓,但这些元素中的部分和标题不会为其祖先的轮廓做出贡献。

    blockquotebodydetailsdialogfieldsetfiguretd

    由于缺乏浏览器和无障碍技术的支持,虽然它“语义上”是正确的,但这并不意味着它是一个好的设计选择。作者应该更喜欢跨部分保留 h1..h6 层次结构,以获得一个连贯的、层次化/嵌套的文档大纲 (h1>h2>h3>...h6) 将提供给辅助技术。

    (*) 请注意,正如另一位用户所指出的那样,必须使用dialog 而不是role=dialog 元素才能获得完全支持。

    【讨论】:

    • 这不再正确(并且从未像最初提议的那样工作):html5doctor.com/computer-says-no-to-html5-document-outline
    • 我不同意它在语义上是有效的。从语义上讲,您是说对话框是整个页面的对等点,而实际上不是。它是在页面的上下文中定义的。这在 HTML 5.1 中并不新鲜,它反映了 &lt;h#&gt; 元素从一开始就是如何设计的。
    • 除了,a) OP 没有使用 &lt;dialog&gt; 元素,b) 拥有自己的轮廓仍然无关紧要,因为没有浏览器支持轮廓算法,并且已在 HTML5 和 @ 中指出987654324@ 应该避免它,并且 c)您提供的 W3C 链接甚至说“作者应该为该部分的嵌套级别使用适当等级的标题。”
    • a) 不,role=dialog 不等于 &lt;dialog&gt;。添加role 永远不会使它等同,无论是对于浏览器还是辅助技术,它只是暴露了它的一些方面(这就是为什么你仍然需要编写键盘支持role=button)。 b) 语义不同于结构。 &lt;h#&gt; 赋予两者,&lt;strong&gt; 仅赋予语义。技术支持对 AT 来说很重要,所以是的,我们正在谈论这一点。 c) 你不清楚。无论如何,它在语义上仍然不正确。
    • 感谢您的 cmets,并帮助我改进我的答案。
    猜你喜欢
    • 2013-01-17
    • 2018-12-28
    • 1970-01-01
    • 1970-01-01
    • 2016-09-04
    • 2021-06-12
    • 1970-01-01
    • 2021-05-18
    • 2011-09-02
    相关资源
    最近更新 更多