【IT之家学院】改善视障用户的网页体验——替代文本的那些事儿( 二 ) 欢迎来到IT之家学院

文章图片

文章图片
绝大多数的屏幕阅读器支持emoji 表情的朗读，但这并不意味着所有用户能理解这个组合表情。因此，我们通过替代文本来告知用户，它具有 “滑稽” 的含义。

文章图片

文章图片
如你所见， aria-label 属性中填充的字符串即为替代文本。在本例中，屏幕阅读器将朗读为 “滑稽按钮” ，及 aria-label 的值与元素类型被读出，控件的 innerText 则被忽略。所以，我们可以很快得出，当 aria-label 与 innerText 同时存在时， aria-label 的优先级高于 innerText。
当你考虑好一切，决定使用aria-label 时，请确保填写了恰当的值。切忌将其设为空值，这虽然不影响屏幕阅读器获取 innerText 的信息，但并不能保障所有的屏幕阅读器都能良好兼容。尤为重要的，控件中 innerText 已经明确传达含义了的，无需额外提供替代文本，除非开发者认为替代文本具有更精准的表达。
通过aria-labelledby 关联标签
从aria-labelledby 这一属性名称上不难察觉，该属性可用于为控件关联替代文本。换言之， dom 中若存在可用的文本，即可通过该属性引用文本的元素 id，使其作为控件的替代文本。令人赞叹的是，该属性还可关联多个元素 id，而你仅需将元素 id 按从左到右的顺序依次排列，并用空格分割， aria-labelledby 将逐一创建关联，并按照你规定的顺序朗读。
例如，一个支持输入页码后跳转页面的编辑框，它所拥有的标签被拆分成了若干个元素，我们就可通过aria-labelledby 这样的神仙属性来关联，而不再需要费劲巴力的通过 aria-label 手动填写了。
第页共5页

文章图片

文章图片
当用户使用tab 键聚焦至该编辑框时，屏幕阅读器将朗读为 “第 1 页共 5 页可编辑文本 1” 。显然， “可编辑文本” 前的内容是我们关联的标签，之后为输入字段的 value 属性值。如果没有关联标签，这样的编辑框在屏幕阅读器下会表现得十分糟糕，如何朗读完全取决于浏览器与屏幕阅读器的配合了。
细心的你或许已经发现，我们将input 的元素 id 一并加入到 aria-labelledby 中，还指定了它的出场顺序，也正如你所看到的， value 的初始值被作为标签的一部分。这样做的好处在于，视障用户编辑字段时，能在标签上直接反馈输入结果，进一步加强了标签的语义化表达。
需要引起重视的是， aria-labelledby 遵循与 aria-label 同样的原则，及确保关联文本具有简明扼要的标签意义。所不同的是， aria-labelledby 的优先级高于 aria-label，当二者同时存在时，仅 aria-labelledby 生效，W3C 也更推崇使用 aria-labelledby。当 DOM 中含有可用文本时，请通过 aria-labelledby 属性关联它，而并非手动填写 aria-label，除非开发者认为后者的表现更为优异。
更易于理解的描述性文本
在非常痛苦的阅读了上述这些味同嚼蜡般的文字后，渐渐地拼凑出了一个脉络，并决定改造自己维护的页面，但沮丧的发现，仍有极个别顽固的组件无法准确传达含义，于是有人可能打算顺着网线摸过来给笔者一顿老拳，我劝你想开些，毕竟本文还没结束，中途下车的拒不退票。
在经过上述步骤，仍然无法精准传达控件含义的，就可祭出终极大法，及aria-description 与aria-describedby 属性。结合此前内容，基本不再需要笔者展开叙述了。aria-description 与 aria-label 用法一致，可供开发者自定义的创建描述信息；aria-describedby 则与 aria-labelledby 对应，可从 dom 中关联可用文本。同样地，描述性文本也具有优先级，aria-describedby 的优先级高于 aria-description，因此W3C 推荐使用 aria-describedby。