本文探讨了 `aria-label` 在 chrome 中误读 html 标签的问题,指出其根源在于将 html 字符串作为 `aria-label` 的值,以及 `div` 元素在无特定 aria 角色时对 `aria-label` 的有限支持。文章提供了 `aria-label` 的正确使用原则,强调其应只包含纯文本,并建议在 `div` 上使用时搭配适当的 aria 角色。此外,还讨论了浏览器与辅助技术的兼容性,并给出了避免此类问题的最佳实践。
在开发无障碍网页时,aria-label 属性是一个重要的工具,它允许开发者为元素提供一个可访问的名称,供屏幕阅读器等辅助技术使用。然而,当 aria-label 的值包含 HTML 标签时,可能会出现意料之外的行为,尤其是在 Chrome 浏览器中与 VoiceOver 等屏幕阅读器结合使用时,辅助技术可能会错误地将 HTML 标签本身也朗读出来。
问题的核心在于 aria-label 属性的设计初衷是接收纯文本字符串作为其值,而不是包含结构化标记的 HTML 片段。当开发者尝试将一个包含 HTML 标签(例如 )的字符串直接赋给 aria-label 时,浏览器和屏幕阅读器可能会尝试解析这个非标准的输入,从而导致不正确的朗读行为。
考虑以下示例代码,它展示了导致问题的不当用法:
如果 translations.content 变量的值是 "How are you",那么最终渲染出的 HTML 将会是:
How are you">
在这种情况下,aria-label 的值被错误地填充了 HTML 标签。Chrome 浏览器在处理这种无效的 HTML 结构时,可能会“猜测”开发者的意图,并可能将 标签本身也视为 aria-label 内容的一部分进行朗读,而非仅仅朗读纯文本“How are you”。
为了确保 aria-label 能够正确地为辅助技术提供信息,并避免不必要的朗读,我们需要遵循以下两个核心原则:
aria-label 的主要目的是提供一个简洁、描述性的文本标签。它不应该包含任何 HTML 标签、实体或样式。如果需要为辅助技术提供更复杂的描述或结构,应考虑使用其他 ARIA 属性,如 aria-labelledby(指向页面上可见的元素)或 aria-describedby。
错误示例:
更多
正确示例:
更多
在上述原始问题中,如果 translations.content 确实需要包含 HTML 结构,那么在将其赋值给 aria-label 之前,应该提取出其中的纯文本内容。
// 假设 translations.content = "How are you"
// 在赋值给 aria-label 之前,提取纯文本
const plainTextContent = new DOMParser().parseFromString(translations.content, 'text/html').body.textContent || '';
// 然后在模板中使用 plainTextContentaria-label 并非适用于所有 HTML 元素。根据 ARIA 规范,aria-label 主要用于那些具有可操作性或具有特定 ARIA 角色(如按钮、链接、表单控件、地标角色等)的元素。对于普通的 div 元素,如果它没有被赋予任何 ARIA 角色,那么 aria-label 可能不会被辅助技术正确识别或支持。
错误示例:
一些内容
正确示例(为 div 添加合适的 ARIA 角色):
如果 div 确实需要一个可访问的名称,并且它扮演着某种语义角色,那么应该为其添加相应的 ARIA 角色。
欢迎
这是页面的主要内容。
@@##@@
在原始问题中,如果 div 只是一个普通的容器,而其内容 How are you 是可见的,那么通常不需要 aria-label。屏幕阅读器会直接朗读 div 内部的可见文本内容。如果 div 内部的文本内容不足以表达其目的,或者内容不可见,才需要考虑使用 aria-label 或 aria-labelledby,并且通常需要为 div 提供一个合适的 ARIA 角色。
值得注意的是,浏览器和辅助技术(如 VoiceOver、JAWS、NVDA)之间的兼容性可能存在差异。某些组合,例如 VoiceOver 与 Chrome,在处理特定 ARIA 属性或复杂 HTML 结构时,已知有时会出现不一致的行为。因此,在进行无障碍开发时,强烈建议在不同的浏览器和辅助技术组合下进行充分的测试,以确保用户体验的一致性。
为了避免 aria-label 误读 HTML 标签的问题,并提升网页的整体无障碍性,请遵循以下最佳实践:
遵循这些原则,将有助于构建更健壮、更易于访问的 Web 应用程序,确保辅助技术能够准确地向用户传达信息。