一、用语义化 Markup 创建用户界面
可访问性不是附加功能，而是专业 Web 开发的基本要求。本单元学习为什么语义化 markup——按预期用途使用元素——是可访问界面的基础，以及 ARIA 如何扩展 HTML 向屏幕阅读器和辅助技术传达复杂的应用交互。
语义化 HTML 与 ARIA——可访问性的基础
语义化 markup 是所有可访问性的基础：按预期用途使用 HTML 元素——<table> 表格数据、<ul>/<ol> 列表、<h1>-<h6> 标题、<button> 可点击动作。为什么重要：屏幕阅读器能导航结构良好的 <table>，但同样的数据放进 <div> 就是一堵无法穿透的文字墙（即使看起来一样）。用 Nu HTML Checker 验证 markup。
ARIA（Accessible Rich Internet Applications）是 HTML 对复杂交互应用的扩展，通过给 HTML 元素应用特殊属性实现。三种 ARIA 属性：
- Roles（角色）——给无语义元素语义：
role="button"、role="menu"、role="dialog"。关键原则：ARIA role 是对用户的承诺——声明 role="button" 就必须实现 button 的全部功能（焦点、键盘 Enter/Space、鼠标点击）。破坏承诺就破坏用户体验。 - States（状态）——描述组件当前条件：
aria-expanded（菜单是否打开）、aria-checked（是否勾选）、aria-selected。必须在用户交互时准确更新。 - Properties（属性）——提供额外上下文：
aria-label（无可见文本元素的可访问名称）、aria-describedby、aria-required。
ARIA 第一法则：能用原生 HTML 就别用 ARIA。<button> 永远优于 <div role="button">——原生元素免费自带可访问性。
二、理解可访问的导航
导航是用户在你的应用中移动的方式——对键盘和屏幕阅读器用户来说，它与基于鼠标的导航有根本不同。覆盖上下文变化（页面更新时通知用户）、焦点管理（动作后键盘光标去哪）、保持用户方向感。
焦点管理与上下文变化
上下文变化——页面无完整重载的更新（模态框打开、区域展开、过滤器应用、列表增删）：屏幕阅读器用户必须被通知发生了变化。用 ARIA live region：aria-live="polite"（当前任务后播报）或 aria-live="assertive"（立即播报）。示例：加购 → <div aria-live="polite">已加入购物车</div>。
焦点管理——键盘光标去哪：关闭模态框后焦点回到打开它的按钮（而非页面顶部）；删除列表项后焦点移到下一项；提交表单后焦点移到成功消息或下一步。没有焦点管理，键盘用户会迷失——Tab 没反应，或焦点跑到意外的地方。
键盘导航原则：所有交互元素可通过 Tab 到达；逻辑 Tab 顺序（跟随页面视觉布局）；不困住键盘用户（模态框除外——把焦点困在内部直到关闭）；监听FOCUS 事件而非特定 Tab 键（屏幕阅读器用户用方向键、标题导航、地标快捷键）。
全局焦点指南（SLDS）：所有交互元素可聚焦、当前焦点元素有可见指示器（永远不要无替代地压制 outline）、动态内容变化后编程式管理焦点。
三、编写可访问的组件
Lightning 组件框架提供预构建、经可访问性审查的组件——尽可能使用。必须构建自定义组件时，遵循 SLDS 蓝图流程：从蓝图开始、实现键盘交互、管理焦点、用自动化和手动键盘测试彻底测试。
正确构建可访问的组件
优先使用现有组件（它们已经可访问）：lightning- 前缀的 LWC 按最新 ARIA 标准和 SLDS 蓝图构建（<lightning-button>、<lightning-input>、<lightning-combobox>、<lightning-datatable>）。即使用预构建组件，你仍有责任：<lightning-icon> 需要 alternative-text、<lightning-input> 需要 label、设置 required="true"。旧的 Aura 组件（ui/force 命名空间）可访问性较差，迁移到 LWC 等价物。
必须自定义构建时——遵循这个流程：① 从 SLDS 组件蓝图开始（蓝图含正确的 ARIA role/state/property、键盘交互规范、焦点管理规则——蓝图就是可访问性规范）② 实现键盘交互（每个 ARIA role 有预期的键盘行为，用真实浏览器写集成测试）③ 管理焦点（可聚焦、可见指示器、动态变化后移动焦点）④ 测试（自动化验证正确语义/属性/生命周期更新；手动用纯键盘做端到端测试——不用鼠标能完成所有任务吗？不能就不可访问）。
Web Components 与 Shadow DOM：Shadow DOM 封装样式但也影响可访问性——焦点管理和 ARIA 引用（aria-describedby、aria-labelledby）不能跨 Shadow DOM 边界。规划组件层级时，相关元素应放在同一个 shadow root。
