我喜欢在我的想法出现时写下一些小的思考。 我们最近 链接 到 Facundo Corradini 的一篇文章,批评了我们的一条推文,我们在其中使用了 <em>
,而我们可能应该使用 <i>
。
Bruce Lawson 检查 是否屏幕阅读器是这些语义错误的受害者……
每当我读到“一些浏览器”或“一些屏幕阅读器”时,我都会问“但哪些呢?”,正如 Ilya Streltsyn 一样,他问我“HTML 现实中文本级语义的现状如何?”
Léonie Watson 来解救! 在 Twitter 上,Watters 写道
大多数都可以在需要时报告这些内容,但并非作为标准。 因此,您在阅读时不会听到文本/字体特征的宣布,但您可以查询字符/单词等以发现其特征。 不过,这是基于文本的视觉呈现,而不是通过对元素本身的任何识别。
我想说的是,如果您真的担心屏幕阅读器错误地解释您语义强调的细微用法…… 您可以放松一下。
Bruce 的文章引导我找到了 Steve Faulkner 2008 年发表的文章 “屏幕阅读器缺乏强调”。
使用语义元素 strong 和 em 不会在典型的浏览条件下向 JAWS 或 Window Eyes 的用户传达任何有用的信息。 虽然了解这一点很重要,但这并不是不使用这些元素来传达含义的理由。 可访问性不仅仅是关于视力障碍者,而是关于所有残疾用户,而 Web 标准也不仅仅是关于可访问性。
因此,在十年中变化不大。 我不清楚事情是否应该在这里发生变化,但如果虚拟语音正在改进,那么它们很可能会在传达强调的语音语调方面变得更好。 当我写这些 HTML 标签时,我当然是在思考语音强调。
这种过度关注可访问性的想法一直是一个主题。
- Eric Baily 阐述了 WIA-ARIA 在误用时如何 弊大于利。
- Jared Smith 回应了一位学生的问题:“网页有可能过于可访问吗?”
- 11 年前,Patrick H. Lauke 创建了一个名为 过度关注可访问性 的演示文稿,涵盖了诸如过于明确之类的内容。
请不要将本文解读为建议我们过度担心可访问性,而仅仅是说,我们有可能担心错误的事情,甚至在过程中破坏可访问性,就像其他任何事情一样。
这里有很棒的小想法。 谢谢!
CSS 删除线是另一个没有被屏幕阅读器真正传达,但具有大量视觉含义的内容。 例如:特价/原价。 这不是语义问题,因为 strike 标签已过时,但处于同一领域。 最好的方法是测试。 创意的 aria-label 或视觉隐藏文本可以在这种情况下构建含义。
<s>
元素未被弃用(<strike>
元素被弃用了,因为无论出于何种原因,它们都有两个……),事实上特价正是规范中提供的示例:https://www.w3.org/TR/html51/textlevel-semantics.html#the-s-element但是,是的,屏幕阅读器不会宣布它(以减少冗长),因此您必须注意在该标签中措辞的文字,以便即使没有提示也能听起来合理。
使用
<del>
标签为已被特价取代的原价提供语义,并将 CSS 删除线附加到该标签。<del>
元素在所有浏览器中都实现了删除线样式,但没有操作系统辅助功能 API 识别它具有任何特殊含义,因此从语义上来说它等同于一个中性的 span 元素。问题在于旧的操作系统辅助功能 API,总体上缺乏大多数文本级语义。
可访问性怎么能太多? 这听起来像是找借口偷懒。 不要只关注当前状态。 也要关注未来状态。
我认为标题并没有像文章中的要点那样很好地传达意思。 本质上,有可能不加思索地将 aria 属性扔到元素上,认为你在帮助用户,而这本身实际上会导致更多问题。
通常,当我看到很多 aria 属性时,这是一个设计方面更大问题的征兆。 例如,如果在 Div 之类的元素上使用
role="button"
。 当然,有些情况下可以这样做,但很多时候,一个普通的按钮就足够了,实际上会更好用。使网站可访问的最佳方法是使用结构良好的语义标记,以及有意遵循最佳实践的可访问设计。 这不应需要太多工作或思考,如果您发现自己不得不这样做,那么您的初始设计出了问题。
这感觉就像一个“我读了标题,现在我要跳到评论区”的评论,对吗?
@chris,这似乎有点过于草率下结论。 以下是我同意 William 的原因
文章的主要观点是,似乎没有当前浏览器以不同/更好的方式呈现某些语义标记,而不是被认为语义性较低的标记。
编写 Web 代码的全部意义不仅仅是为了让它在今天能用,它必须具有前瞻性,并且能在未来的浏览器中也能用。 W3C 一直试图引导开发者走向一个更语义化的 Web,并建议使用
<em>
代替<i>
,如果文本需要的不只是视觉强调。作为负责任的开发者,我们不应该满足于仅仅让事情能用,我们应该尝试考虑还没有出现的情况。 这就是响应式设计不仅仅是为了让网站在特定固定尺寸的移动屏幕上能用的原因。 这就是我们努力使内容对用户的连接速度做出反应的原因,即使我们不知道我们的用户可能具备什么条件。 这就是我们不断学习新技术的原因,因为我们始终希望具有前瞻性。
我完全同意我们可能会搞砸可访问性,但我认为这不是因为我们太努力了,而是因为我们不理解。 在一个充斥着
<div>
的页面上随意扔 aria 属性是错误的。 这看起来是正确的,因为我们在上面花了大量时间,所以我们很努力,但我们努力的方向错了。 ARIA 只是在语义标记失败时才作为一种辅助工具;但语义标记应该始终是王道。所以,这就是我同意 William 的原因。 我们必须注意我们的标记,不幸的是,这篇文章似乎没有提供最佳建议(或者至少没有以最佳方式提供最佳建议)。
“11 年前,Patrick H. Lauke 创建了一个演示文稿……”天哪,我现在感觉自己老了……
我在 StackOverflow 上花太多时间告诉人们,他们不需要强迫隐藏文本以他们想要的方式朗读日期或价格,仅仅因为屏幕阅读器没有按预期朗读。 当我们把技术视为我们的目标而不是用户时,过度设计很容易发生。
关于在屏幕阅读器中宣布
<em>
,Steve Faulkner 也写了一篇关于如何让<mark>
可发现的优秀文章:https://developer.paciellogroup.com/blog/2017/12/short-note-on-making-your-mark-more-accessible/我把它扩展到处理
<del>
、<ins>
和<s>
,不仅仅是针对屏幕阅读器:http://adrianroselli.com/2017/12/tweaking-text-level-styles.html为了回到 Chris 的观点,随着 NVDA 添加对
<del>
和<ins>
的支持,我网站上的一些用户现在会体验到过度的可访问性:https://github.com/nvaccess/nvda/pull/8558这些语义元素将来可能具有隐式角色:https://github.com/w3c/aria/issues/698
问题在于屏幕阅读器正在弥补我们没有提供良好语义代码的缺陷。如果我们正确地使用
<em>
标签,它们早就能够添加语音强调,听起来更像人类了。当我们使用诸如<i lang="fr">
之类的东西时,它们会切换到正确的发音,添加强调应该要简单得多。