【学习】什么是Accessibility - 无障碍
最近在学习TailWindCSS,读和整理文档准备拿去做个项目(就决定拿来重构之前的简历项目了)了解到了无障碍 Accessibility 这个概念,很多指导性概念值得学习,就写篇文章了
Accessibility - 无障碍
当有人将一个网站描述为“无障碍”时,他们的意思是,任何用户都可以使用其所有的功能和内容,无论用户是如何访问网络的——甚至特别是有身体或精神障碍的用户。
默认情况下,HTML 在使用正确的时候是可以实现无障碍的。Web 无障碍涉及确保内容保持无障碍,无论访问 web 的人员或方式。
无障碍是一种让尽可能多的用户可以使用你的网站的做法。传统上我们认为这只与残疾人士有关,但提升网站的无障碍也可以让其他用户群体受益。比如使用移动设备的人群,那些使用低速网络连接的人群。
你也可以把无障碍看成是同等地对待每一个人,给他们平等的机会,无论他们的能力或所处的环境如何。就像不能让坐轮椅的人可以进入大楼是错误的 (现代公共建筑通常有轮椅坡道或电梯);不能让视觉有障碍的人士可以浏览我们的网站同样不正确。我们都是不同的,但我们都是人,因此享有同等的人权。
使网站具备无障碍才是正确的做法。它也是一些国家法律的一部分,它打开了一些重要的市场,否则那些市场的用户无法使用你的服务或者购买你的产品。
建立可访问的网站能让每个人都受益
无障碍 API
不同的操作系统有不同的无障碍 API:
- Windows: MSAA/IAccessible, UIAExpress, IAccessible2
- Mac OS X: NSAccessibility
- Linux: AT-SPI
- Android: Accessibility framework
- iOS: UIAccessibility
在 WAI-ARIA basics 文章中了解有关 WAI-ARIA 的更多详细信息。
https://developer.mozilla.org/zh-CN/docs/Learn/Accessibility/WAI-ARIA_basics
HTML 无障碍的良好基础
- 良好的语义 (HTML 结构)
- 更便于开发 — 如上所述,你可以使 HTML 更易于理解,并且可以毫不费力的获得一些功能。
- 更适配移动端 — 语义化的 HTML 文件比非语义化的 HTML 文件更加轻便,并且更易于响应式开发。
- 更便于 SEO 优化 — 比起使用非语义化的
<div>
标签,搜索引擎更加重视在“标题、链接等”里面的关键字,使用语义化可使网页更容易被用户搜索到。
- 使用通俗易懂的语言
- 页面布局(同上,HTML5 新标签 - 语义化)
- UI 控制
- 重新建立键盘的无障碍
- 有意义的文字标签
- 可访问的表格
- 表头使用
<th>
元素定义 - 你还可以使用 scope 属性指定它们是行还是列的标题。这提供给了屏幕阅读器可以理解的完整数据组。 <caption>
元素和<table>
summary 属性都执行类似的工作 - 它们充当表格的替代文本,为屏幕阅读器用户提供有用的表格内容快速摘要。<caption>
通常是首选,因为它使内容可供视力良好的用户访问,而且他们也可能会发现它很有用。你并不需要两者都使用!。
- 表头使用
- 图片拥有可替代文本
- title
- alt
你现在应该精通编写大多数场合可访问的 HTML。我们的 WAI-ARIA 基础知识文章也将填补这些知识中的一些空白,但本文已经关注了此基础知识。接下来,我们将探索 CSS 和 JavaScript,以及无障碍如何受其好坏影响。
CSS 无障碍
正确的语义和用户期望,对
h1
span
等选择合理的字体大小、行高、字母间距等,使文本具有逻辑性、清晰性和阅读舒适性。
确保标题从正文文本中脱颖而出,通常像默认样式一样大而粗壮。你的列表应类似于列表。
文本颜色应与背景颜色形成良好对比。
强调的文本
b
strong
i
缩写
<abbr>
超链接 a
表单元素
表格
颜色和颜色对比度
- 为网站选择配色方案时,请确保文本(前景)颜色与背景颜色对比度良好。你的设计可能看起来很酷,但如果有视觉障碍(如色盲)的人无法阅读你的内容,则设计就无一好可做。
接受用户覆盖样式
JavaScript 无障碍
JavaScript 还可能会中断无障碍,具体取决于其使用方式。简单的内容和功能可以说是很容易使访问——例如文本,图像,表格,窗体和按钮,激活功能。正如我们在 HTML:辅助功能的良好基础一文中提到的,主要注意事项包括:
- 良好的语义:为正确的工作使用正确的元素。例如,确保你使用标题和段落,以及
<button>
和<a>
元素 - 确保内容以文本形式提供,要么直接作为文本内容、表单元素的良好文本标签,也可以确保替代文本(例如图像的 alt 文本)。
太多 JavaScript 导致的问题
过于依赖 JavaScript 会导致许多问题。有时你会看到一个网站,其中一切都已经用 JavaScript 完成——JavaScript 生成 HTML,CSS 等等。随之而来的会是各种访问性问题,因此这样做是不建议的。
保持别抢眼
在创建内容时,应牢记不唐突的(unobtrusive)JavaScript 原则。不唐突的 JavaScript 的想法是,它应该尽可能用于增强功能,而不是完全构建它——基本功能最好在没有 JavaScript 的情况下正常工作,尽管人们认识到,这并不总是一个选项。但同样,它的大部分是尽可能使用内置的浏览器功能。
- 提供客户端表单验证,它快速提醒用户表单条目出现的问题,而无需等待服务器检查数据。如果表单不可用,则窗口仍然有效,但验证速度可能较慢。
- 为 HTML5
<video>
提供自定义控件,这些控件仅供键盘用户访问,以及如果 JavaScript 不可用 (默认<video>
浏览器控件在大多数浏览器中无法使用键盘访问),就直接通过链接访问视频。
在实现 JavaScript 和考虑无障碍时,还有其他需要注意的事项。一旦发现将会添加更多。
正如你所知,客户端 JavaScript 使用事件处理程序,实现大多数用户交互,它允许我们运行函数以响应某些事件的发生。某些事件可能有辅助功能问题。你将遇到的主要示例是鼠标特定的事件,如鼠标悬停(mouseover (en-US))、鼠标划出(mouseout)、双击(dblclick)等。使用其他机制(如键盘控件)无法访问为这些事件而运行的功能。
为了缓解此类问题,你应该将这些事件与可以通过其他方式(所谓的设备独立事件处理程序)激活的类似事件相结合——focus 和 blur 将为键盘用户提供无障碍。
Click 事件很有趣——听起来它依赖于鼠标,但是大多数的浏览器,在有焦点的链接或者表单元素上,按下 enter/return 之后,或者在触屏设备上点击一个元素,都将会激活 onclick 事件处理程序。但是,当你允许非默认可聚焦事件使用 tabindex 进行焦点处理时,默认情况下不起作用,在这种情况下,你需要在按下确切键时进行专门检测
何为 WAI-ARIA
WAI-ARIA 是 W3C 编写的规范,定义了一组可用于其他元素的 HTML 特性,用于提供额外的语义化以及改善缺乏的无障碍。以下是规范中三个主要的特性:
角色 — 这定义了元素是干什么的。许多「标志性的角色」,其实重复了 HTML5 的结构元素的语义价值。例如 role=”navigation” (
<nav>
) 或者 role=”complementary” (<aside>
),这也有一些描述其他页面结构的(角色),例如 role=”banner”, role=”search”, role=”tabgroup”, role=”tab” 等等。我们通常能从 UI 层面找到它们。属性 — 我们能通过定义一些属性给元素,让他们具备更多的语义。例如: aria-required=”true” 意味着元素在表单上是必填的。然而 aria-labelledby=”label” 允许你在元素上设置一个 ID,用于 labelledby 引用作为屏幕阅读器指定的 label 内容,多个也可以。当然,下面这个代码是不行的:
<label for="input">
状态 — 用于表达元素当前的条件的特殊属性,例如 aria-disabled=”true”,屏幕阅读器就会这个表单禁止输入。状态和属性的差异之处就是:属性在应用的生命周期中不会改变,而状态可以,通常我们用编程的方法改变它,例如 Javascript。
但还是要重申:当你需要的时候再使用无障碍特性!另外,请尝试确保你的真实用户来测试你的网站:普通人,使用屏幕阅读器的用户,使用键盘导航的人。他们会提供你更多的见解。
实用的 WAI-ARIA 实现
WAI-ARIA 给浏览器增加了 role 属性,这允许我们给站点中的元素增加我们想要的语义属性。第一个主要区域便是用于为屏幕阅读器提供信息,以便用户可以找到常见的页面元素。
如果由于某种原因,你的网站仅使用<div>
构建,那么你肯定很需要用 ARIA 角色以提供所需的语义!
动态内容更新
使用屏幕阅读器可以轻松访问读取到 DOM 中的内容,从文本内容到附加到图像的 alt 文本。所以具有大量文本内容的传统静态网站易于为视碍人士提供信息。
WAI-ARIA 提供了一种有效的机制来发起提示——aria-live
。将此应用于元素会让屏幕阅读器读出更新的内容。读取内容的紧急程度取决于属性值:
- off: 默认值,更新不会提醒。
- polite: 只有用户空闲的情况下提醒。
- assertive: 尽快提醒。
- rude: 会以打断用户操作的方式直接提醒。
通常来说 assertive 设置足以让你的更新在显示时按时序读出,因此,如果改变多次,那么他只会念出最后一个改变。除非紧急程度高到需要覆盖其他的更新才选择使用 rude 。
优化键盘的无障碍操作
正如上下文中其他几处讨论的,HTML 在无障碍方面的关键优势之一是按钮,表单控件和链接等功能的内置键盘无障碍。平时你可以使用 Tab 键在控件之间移动,使用 Enter / Return 键选择或激活控件,偶尔也可以根据需要使用其他控件(例如上下光标在<select>
框中的选项之间移动)。
但是在一些时候,你最终还是得编写代码去使用非语义元素作为按钮(或其他类型的控件),或者使用可聚焦控件来达到错误的目的。你可能正在尝试修复一些你之前的错误代码,或者你可能正在构建某种需要它的复杂小部件。
在让不可聚焦代码可聚焦这一方面,WAI-ARIA 用一些新的值来扩展了 tabindex 的属性:
- tabindex=”0” — 如上所述,这个值让不能被 tab 的元素变得 tabbable。这是 tabindex 最有用的值。
- tabindex=”-1” — 这允许通常不可列表的元素以编程方式来接收 focus。例如用:JavaScript,或者作为链接的目标。
非语义控件的无障碍
当一系列嵌套的 <div>
与 CSS / JavaScript 一起用于创建复杂的 UI 功能,或者通过 JavaScript 大大地增强或者更改原生的控件,不仅键盘无障碍受损。而且如果没有语义或其他线索,屏幕阅读器用户会发现很难弄清楚该功能的作用。在这种情况下,ARIA 可以帮助提供那些缺失的语义。
你可以在这里看这个在线完成的例子 form-validation-updated.html
描述非语义的 button 是个 button
1 | <div data-message="This is from the first button" tabindex="0" role="button">Click me!</div> |
备注: 别忘了无论如何用正确的语义化元素是最佳选择。如果你想创建一个按钮,你可用
<button>
元素,你应该用<button>
元素!
通过复杂的小部件做引导用户
还有许多其他 roles 可以将非语义元素结构识别为常见的 UI 功能,这些功能超出了标准 HTML 中可用的功能,例如 combobox, slider, tabpanel, tree。
以下刚刚用上的新特性:
新角色 — tablist, tab, tabpanel — 这些确定几个 tab 表界面的重要区域——tabs 的容器,tabs 自身,还有他们的一致性 tabpanels。
aria-selected — 定义了 tab 当前正在被选中。和 tabs 被用户选中不同,这种值一般是由 JavaScript 修改。
aria-hidden — 对屏幕阅读器隐藏一些元素,和 tabs 被用户选中不同,这种值一般是由 JavaScript 修改。
tabindex=”0” — 当我们删除链接时,我们需要为列表项提供此属性,以便为其提供键盘焦点。(为没有 tabindex 特性的元素也提供 tabindex 特性)
aria-setsize — 此属性允许你指定屏幕阅读器元素是某个系列的一部分,以及该系列具有多少项。
aria-posinset — 这个属性允许你设置一个元素在一个系列中的位置,随着 aria-setsize,他告诉屏幕阅读器(用于设置文件目录树视图)足够的信息去告诉你现在在 item “1 of 3” 位置等。
如果你有不想让屏幕阅读器读出来的东西,你可以给它一个 aria-hidden=”true” 属性。
多媒体无障碍
可能导致无障碍(accessibility)问题的另一类内容是多媒体——视频、音频和图像内容需要提供适当的文本替代方式,以便辅助技术及其用户能够理解它们
简单图像
简而言之,应确保在可能的情况下,视觉内容具有替代文本,供屏幕阅读器拾取和读取给其用户。
1 | <img src="白雪公主.png" alt="您正在看的是《白雪公主和七个小矮人》绘图本,白雪公主的图片" /> |
可访问的音频和视频控件
HTML5 视频和音频实例甚至附带一组内置控件,允许你直接在盒子控制媒体。
1 | <audio controls> |
但是,这些控件存在问题:
- 浏览器中,它们不可通过键盘访问。
- 不同的浏览器为原生控件提供了不同的样式和功能,且不可赋予它们样式,这意味着它们难以遵从网站样式指南。
这里是推荐我们根据上文自行实现 role 和 控件细节,补充描述和键盘事件等,这里就不展开了
移动端无障碍
如今,移动设备一般都可以处理特性齐全的网站了,同时,为了能够让盲人成功的使用网站,主流平台甚至还内置了屏幕阅读器。移动设备也倾向于对“WAI-ARIA”有很好的支持。
你只要需要遵守良好的 web 设计规范和最佳的无障碍实践,就可以让你的网站在手机上无障碍地使用。
移动设备需要特别考虑一些例外情况;主要是:
- 控件交互——确保类似于按钮的 UI 控件可以在移动端(主要是触摸屏)和台式机/笔记本电脑(主要是鼠标/键盘)无障碍地使用
- 用户输入——在移动端尽可能的减少用户输入的要求(例如在表单中,尽量少打字)。
- 响应式设计——确保移动端布局正常的情况下,节省需要下载的图片大小,并考虑为高分辨率的屏幕提供图片。
响应式设计
响应式设计是根据屏幕大小和分辨率等因素动态更改你的应用程序的布局和其他功能的做法,因此对于不同设备类型的用户来说,它们是可用且无障碍的。
特别是,移动端设备需要解决的最常见的问题是:
移动端设备布局的适用性。例如,在窄屏上多列布局不能很好的工作,需要增加文字大小以提高可读性。这些问题可以通过媒体查询、视口、弹性盒子来解决。
节省下载的图片大小。一般来说,小屏幕设备不需要与桌面设备一样大的图像,而且它们将更可能在慢速网络连接上。因此,适当地缩小屏幕设备以缩小图像是明智的。你可以使用响应式图像技术处理此问题。
考虑高分辨率。许多移动设备具有高分辨率屏幕,因此需要更高分辨率的图像,使得显示器可以继续看起来清晰和锐利。再次,你可以使用响应式图像技术来适当地提供图像。此外,使用 SVG 矢量图像格式可以满足许多图像要求,这些格式在目前的浏览器中得到了很好的支持。SVG 文件较小,且不论以何种大小显示,它都会保持清晰
具体的需要注意的点
- 不禁用缩放 使用视口可能会禁用缩放。要始终启用缩放,请在
<head>
中将宽度设置为设备宽度:
1 | <meta name="viewport" content="width=device-width; user-scalable=yes" /> |
但国内行情一般都是禁用这项的。至于具体怎么使用,仁者见仁智者见智吧
- 保持菜单无障碍
因为移动设备上的屏幕非常窄,所以使用媒体查询和其他技术使得导航菜单缩小到显示屏顶部的一个小图标,只有在需要的时候才展示菜单,这种方式在移动设备上很常见的。这通常由“三横线”图标表示,并且设计模式因此被称为“汉堡菜单”。
- 用户输入
在移动设备上,输入数据往往比在台式计算机上的同等体验更令用户恼火。使用桌面或笔记本电脑键盘输入文本到表单输入比触摸屏虚拟键盘或微小的移动物理键盘更方便。
出于这个原因,值得尽量减少所需的输入量。例如,与其让用户每次使用常规文本输入来填写他们的工作标题,而是可以提供一个 <select>
菜单,其中包含最常见的选项(这也有助于数据输入的一致性),并提供一个“其他”选项,显示一个文本字段来输入任何异常值。
也值得考虑在移动平台上使用 HTML 格式输入类型(如日期),因为它们可以得到很好的处理。例如,Android 和 iOS 都会显示可用于设备体验的可用控件。
总结
在本文中,介绍了什么是无障碍,为什么需要无障碍,在HTML、CSS、JavaScript中我们能为无障碍做哪些事情以及移动端下的表现,添加响应式设计。WAI-ARIA为W3C的规范,在使用多媒体元素时,我们可做的事情。
需了解更多可查看官方文档,这里大致做一个了解即可