网站的可访问性 (Accessibility)
- 文章發表於
前言
我还记得刚踏入职场时，常常在 X 上看到许多国外大神分享他们的产品已经符合无障碍标准，又或是他们的设计系统全面支持 A11y 等等的关键字。
当时只觉得：“又有新东西出现！！真的学不动了...”且心想，这该不会又是个短暂的风潮，撑不过一季就退烧吧？
直到刚加入一家美国初创后，初期收到的任务大多还算简单，但让我讶异的是这些任务几乎都是跟无障碍 (Accessibility) 有关的修正或优化，像是让键盘能顺利操作、让屏幕阅读器能正确朗读内容等等。
这才发现，原来公司近期正全面推动网站的无障碍支持，也才开始理解，美国法律对网站的可访问性（Accessibility）有一定的要求，如果网站做得不够完善，是有被用户提告的风险。
根据 2021 年的资料，美国约有 4,250 万名身心障碍者，占总人口的 13%。这个族群涵盖了在听力、视力、认知、行走、自我照顾或独立生活等方面有困难的人。回头看台湾，根据 卫生福利部统计 有近 120 万人是身心障碍者，占总人口的 4.2%。
从身心障碍者的角度来看，如果一个产品无法让他们顺利使用，那是否为一种不公平；而从商业的角度来说，缺乏可访问性的产品，则意味着直接流失这一群潜在用户。那时我才知道可访问性如此重要，也才开始认真学习相关的知识。
什么是可访问性？
许多可访问性的功能不仅仅是身障使用者受益，也对所有使用者带来了更好的可用性和包容性。以“高对比色彩”为例，不只能帮助视力较差的使用者，也对其他情境中的使用者同样有益，像是在阳光强烈的户外使用手机，或是在灯光昏暗的房间里操作装置时，都能提升可读性与能见度，减轻眼睛疲劳，进而提高整体清晰度与使用效率。
重要的原则
可感知性 (Perceivable)
信息与用户界面必须能够被所有人以某种形式感知。也就是说，不论使用者通过哪种感官或辅助工具，都应该能接收到内容。
可操作性 (Operable)
所有使用者都应能操作界面与进行导航。举例来说，网站必须支持键盘操作，不能只依赖鼠标，确保每个人都能顺利使用功能。
可理解 (Understandable)
信息内容与界面互动方式应容易理解。举例来说，系统应能协助朗读内容、提供摘要，帮助有认知障碍的使用者理解页面。
强健 (Robust)
内容必须具备良好的兼容性，能被多种用户代理（User Agent）与辅助技术正确解析与呈现，确保系统具备跨平台与未来的可延展性。
可访问性的四个最佳实践
以下列出四个在实现阶段特别需要留意的重点，这些原则皆参考 WCAG (Web Content Accessibility Guidelines) 的规范。我们也会在后续设计系统的元件开发中，针对这些部分特别强化与实现。
颜色对比度
提供足够的对比度，能确保使用者清楚看见文字与图像内容。特别是在文字置于图片上时，必须确保两者之间的对比度足够，才能维持良好的可读性。
以下图为例，图中上方的颜色对比度是 1.61:1，而下方则是符合 WCAG 的 8.39:1，可以明显看出下方的文字更容易阅读。
语义化标签
语义化标签是指使用 HTML 标签来描述网页的内容，让浏览器和屏幕阅读器能够更好地理解网页的内容。对于无障碍设计来说，尽量使用 <header>、<nav>、<main>、<footer> 来包装内容，主要是因为如果使用 <div> 或 <span> 来包装内容，屏幕阅读器会无法判断这些元素的意义。
无障碍树 (Accessibility Tree)
在一般的浏览器渲染流程中，浏览器会先解析网页标记语言（例如 HTML），建立一棵 DOM 树（Document Object Model），其中包含页面上的所有元素、属性与文字节点。同时，浏览器也会解析 CSS，产生 CSSOM。DOM 与 CSSOM 结合后，产生用于排版的 Render Tree，接着经过版面配置（layout）与绘制（paint）步骤，最终显示到屏幕上。
与此流程“并行”的还有无障碍树（Accessibility Tree）：浏览器会依据 DOM 结构、ARIA 属性及计算后的样式，建立这棵树，并提供给屏幕阅读器等辅助技术存取。藉由无障碍树，身心障碍者得以感知、理解并操作我们的网站内容。
无障碍 API（Accessibility API）
当我们想把元件的语义、名称与状态暴露给无障碍树时，就需要利用浏览器／操作系统提供的无障碍 API。每个暴露的节点会被包装成一个 Accessible Object，其中最常见的四大属性如下：
| 属性 | 作用 | 常用实现方式 |
|---|---|---|
| Role（角色） | 指出元素在界面中的语义角色，如 button、checkbox、link… | role="button"、role="checkbox"… |
| Name（名称） | 让使用者知道“这是什么” | <label>、aria-label、aria-labelledby |
| State／Property（状态／属性） | 告知目前状态，如已勾选、已展开、禁用… | aria-checked、aria-expanded、disabled |
| Description（描述） | 额外说明用途或限制 | aria-describedby |
示例代码
自定义按钮元件的角色 (Role)
<!-- div 原本没有语义，需加 role 与 tabindex --><div role="button" tabindex="0">点我</div>提供名称 (Name)
<!-- 通过 label 绑定 --><label for="search">搜索：</label><input id="search" type="text" /><!-- 或改用 aria-label 直接指定 --><input type="text" aria-label="搜索关键字" />自定义核取方块的状态 (State)
<div role="checkbox" aria-checked="false" tabindex="0">订阅电子报</div>备注： 原生
<input type="checkbox">已内置可存取性信息，一般不需再加aria-checked。额外描述 (Description)
<label for="username">用户名：</label><input id="username" type="text" aria-describedby="usernameHelp" /><p id="usernameHelp">用户名需包含 6–12 个字符，且不得含特殊符号。</p>
如果想要了解更多关于无障碍 API 的详细信息，可以参考 WICG AOM Explainer。
键盘焦点 (Keyboard Focus)
键盘焦点是浏览器目前接收键盘输入的元素。当使用者以键盘浏览网站时，焦点就像他们的游标；所有可互动元件都必须能通过键盘操作（例如 Enter、Space、Tab 等键）存取。此外，焦点的移动顺序应按照由上而下、由左至右的 DOM 排序，确保使用体验流畅。
另一点需特别留意：当使用者点击按钮开启 Modal 窗口时，应立即将键盘焦点移入 Modal；在关闭 Modal 后，则需把焦点还给原本的按钮。后续的文章会实现相关元件，完善这套焦点管理流程。
Accessibility 测试工具
延伸阅读
