构建可访问性完备的UI组件库需将A11y融入全流程：遵循WAI-ARIA标准，优先使用语义化HTML和原生元素，避免div模拟按钮；为自定义组件添加role、aria-label等属性；确保表单有label关联；模态框设置aria-modal并管理焦点进出；支持键盘导航，保持聚焦顺序与视觉一致，复合组件支持方向键；提供可见焦点指示器；文本对比度达标，错误提示结合图标与文字；状态变化多方式表达；集成axe-core等工具至CI进行自动化测试，配合手动测试与残障用户反馈。
构建一个可访问性（A11y）完备的UI组件库，核心在于将无障碍设计融入开发流程的每个环节。不能把A11y当作后期补丁，而应作为基础要求贯穿设计、编码、测试和文档全过程。
遵循WAI-ARIA标准并正确使用语义化HTML
大多数可访问性问题源于语义缺失或错误的标签结构。优先使用原生HTML元素（如 button、input、nav），因为它们自带无障碍特性。
- 避免用 div 或 span 模拟按钮，应使用 ，确保键盘可聚焦和屏幕阅读器正确识别
- 为自定义组件添加正确的 role、aria-label、aria-expanded 等属性
- 确保表单控件有对应的 label，使用 for 和 id 关联
- 为模态框设置 aria-modal="true"，并管理焦点进出
键盘导航与焦点管理
许多用户无法使用鼠标，完全依赖键盘操作。组件必须支持完整的键盘交互。
- 所有可交互元素必须能通过 Tab 键聚焦，且顺序符合视觉逻辑
- 复合组件（如下拉菜单、选项卡）需支持方向键操作
- 打开模态框时，焦点应移动到内部第一个可聚焦元素，并限制在框内循环
- 关闭模态框后，焦点应回到之前触发的元素
- 提供可见的焦点指示器，避免移除 outline 样式
颜色对比与视觉提示冗余
视觉障碍用户可能色弱或低视力，不能仅靠颜色传递信息。
- 文本与背景的对比度至少达到 4.5:1（大文本 3:1）
- 错误提示不能只用红色，应配合图标或文字说明
- 状态变化（如成功、警告）使用多种方式表达
- 支持高对比度模式，避免固定样式覆盖系统偏好
自动化测试与持续验证
人工测试难以覆盖全部场景，需结合工具进行持续检查。
- 集成 axe-core、pa11y 等工具到CI流程，自动扫描组件快照
- 编写单元测试验证 ARIA 属性是否正确更新
- 定期使用屏幕阅读器（如 NVDA、VoiceOver）手动测试关键路径
- 邀请残障用户参与可用性测试，获取真实反馈
基本上就这些。A11y 不是功能清单，而是对所有用户尊重的设计态度。从第一天开始做正确的事，比后期修复更高效也更彻底。
