web-accessibility

用途：帮助设计与审查无障碍网页界面，把无障碍当作残障用户成功完成任务与恢复错误的能力，而非工具分数。做法是先定义可观察需求，再实现，最后在受支持浏览器与辅助技术（AT）环境中收集限定范围的证据。\n\n主要能力：提供按需加载的参考文件与模板，覆盖原生语义与无障碍名称、键盘与焦点及路由、表单错误与认证、对话框与展开式导航、复合控件、视觉与输入及动效、测试与证据、源索引、路由边界和结果探针。流程包括：用接受标准模板定义任务、用户、支持的浏览器/AT、输入方式与失败恢复；优先选用原生 HTML；为每个交互状态明确触发、角色/名称/状态/值、键盘命令、焦点进入退出与返回、指针替代、错误与可见反馈；按视觉与输入适配参考，区分 WCAG 要求与产品目标；契约确定后再实现，自定义复合控件应先评估成熟的原生或维护中的组件；最后按测试与证据参考及设计、实现、发布模板验证，记录工具、版本、范围、人工任务、实际浏览器/AT 组合、失败及被阻塞或不适用项。\n\n用法要点：仅当原生宿主语言语义无法提供所需行为时才用 WAI-ARIA 1.2；ARIA 改变语义，不创建键盘行为或视觉呈现。无障碍名称与描述边缘情况使用名称与描述计算 1.2 算法，并检查计算后的无障碍树。模态框在支持目标环境时优先用 <dialog>.showModal()，保持背景不可用/惰性，选择合适初始焦点，提供可见关闭路径并合理返回焦点，不用 aria-hidden 隐藏背景或对话框祖先。普通响应式导航按普通链接上的展开式处理，不用 ARIA 菜单语义，除非采用应用菜单键盘契约。WCAG 2.2 AA 的目标尺寸最小为 24×24 CSS 像素，适用其间距、等效、行内、用户代理与必要例外。\n\n限制：不要用自动扫描发布 WCAG 符合性或一般无障碍结论；符合性声明需要完整、限定范围的评估，超出本技能的自动判定。每个接受标准需有直接证据或记录的失败、阻塞、不适用结果，并报告剩余风险与证据边界，缺失测试不得当作通过。Hugo 模板架构、主题布局或 CMS 渲染用 hugo-theme；证据收集、范围决策或无障碍之外的用户行为用 product-discovery、product-methodology 或 product-design-and-ux；框架或库 API 在定义语义与交互契约后查最新官方文档，React 实现细节路由到 react，Vite 配置路由到 vite。