AI辅助编程中无障碍检查的实践：从设计到代码的内置思维

1. 项目概述在设计与构建阶段内嵌的无障碍检查思维作为一名长期在Web前端和交互设计领域摸爬滚打的从业者我见过太多项目在临近上线甚至上线之后才被测试或用户反馈“这个按钮读屏软件读不出来”、“键盘没法操作这个弹窗”。这时候再回头修补成本高昂且往往治标不治本因为问题根源在于早期的设计和编码决策。最近我在探索AI辅助编程工具如Claude Code、Cursor时发现了一个名为accessibility-linter的开源技能Skill它提出了一种革命性的思路将无障碍A11y检查从“事后审计”转变为“设计构建时的即时对话”。这不仅仅是又一个代码检查工具而是一种旨在改变开发者与设计师工作流的“设计工程”思维。这个项目的核心主张是糟糕的无障碍体验是一个结构性问题。一个混乱的焦点顺序意味着页面或组件的层级结构本身就有问题一个没有标签的按钮意味着这个交互动作在设计时只有视觉暗示从未被明确命名一个仅用颜色表示的错误状态意味着状态被“样式化”了却没有在代码逻辑中被“建模”。accessibility-linter就是为了在设计中期捕捉到这些决策追问其背后的结构性原因从而从一开始就将正确的模式“烘焙”进代码里。它覆盖了语义化HTML、ARIA、键盘导航、焦点管理、组件状态、色彩对比度、动效和触摸目标等关键领域。接下来我将深入拆解这个项目的设计理念、实操集成方法并分享如何将其核心思想融入日常开发流程让你在“ vibe prototyping”氛围原型设计时代也能产出坚实可访问的产品。2. 核心设计理念与工作模式解析2.1 从“报告”到“对话”设计工程思维的实践传统的无障碍工作流通常是线性的设计 - 开发 - 测试包含无障碍审计- 修复。accessibility-linter试图打破这个链条将无障碍考量注入到“设计”和“开发”这两个创造性阶段本身。它模拟的是一位资深设计工程师Design Engineer在你身边进行代码评审Code Review时的行为即时、聚焦、具有建设性。它的工作模式分为三个层级这构成了其核心逻辑第一层默认内置Tier 1: Built-in by default对于已成最佳实践的基础模式它不会询问而是直接实施。例如当你描述“一个提交按钮”时它会自动生成button typesubmit提交/button而不是div classbtn提交/div它会为图标按钮补充aria-label它会为可交互元素添加基础:focus样式。它的理念是这些不应该是一个需要讨论的选项而是“完成”状态的组成部分。这相当于在团队中确立了一种不容妥协的代码标准。第二层构建前询问Tier 2: Asked before building对于那些具有深远结构性影响的决策它会在编写代码前提出一个关键问题。例如当你打算创建一个模态对话框Modal时它不会直接生成代码而是会问“这个模态对话框是模态的吗即是否应该用aria-modal“true”并捕获焦点请描述关闭它的方式ESC键、点击遮罩、特定按钮。” 它关注的是键盘导航模型、焦点管理策略、实时区域Live Region的更新机制等。这些问题如果在后期修改往往意味着组件逻辑的重构因此在构建前明确意图至关重要。第三层有意识的偏离Intentional deviations无障碍规则并非铁律在特定上下文中打破规则可能是正确的选择。例如在一个包含未保存内容的表单模态框中禁用ESC键以防止误关闭是合理的。此时accessibility-linter会识别出这是一个对默认行为的“偏离”它会明确指出这个权衡“这阻止了键盘用户快速放弃操作请确认”并要求开发者明确确认此意图。这确保了任何对无障碍约定的违反都是经过深思熟虑的而非疏忽。实操心得这种分层模式非常高明。它区分了“规范”必须做、“架构”需要设计决策和“例外”需特别批准。在实际团队协作中我们常常纠结于哪些规则必须遵守哪些可以酌情处理。这个工具通过其行为本身为我们提供了一套清晰的决策框架。2.2 覆盖范围与能力边界理解一个工具能做什么和不能做什么与知道它能做什么同样重要。它覆盖的核心领域包括语义化HTML确保使用正确的元素表达正确的含义。ARIA在HTML语义不足时用ARIA属性补充可访问性信息并避免ARIA误用。键盘导航与焦点管理确保所有功能都能通过键盘访问且焦点移动符合逻辑。组件状态确保组件状态如展开/折叠、选中/未选中不仅通过视觉也通过辅助技术API暴露。色彩对比度在涉及色彩表达信息时如错误状态、图表会提醒对比度要求。动效与触摸目标关注可能引发前庭障碍的动效以及移动端上足够大的触摸区域。它明确不是一个完整的WCAG审计工具它不生成合规报告不检查所有WCAG成功标准。它专注于在编码时预防最常见、最结构性的问题。一个自动化linter或CI插件它不是在你提交代码后运行的静态检查工具。它参与的是编码的“创作过程”。一个上线后审查工具它的主战场是设计和构建阶段。一个最终检查清单它反对将无障碍作为最后一道关卡主张将其内化为开发习惯。这种定位使其非常适合当前流行的“AI辅助编程”和快速原型vibe prototyping场景。在这些场景中开发速度极快如果不在生成代码的瞬间引入约束很容易积累下大量的技术债务。3. 多平台集成与实操配置指南accessibility-linter的本质是一个高度结构化的“系统提示词System Prompt”其核心内容位于项目根目录的SKILL.md文件中。因此它可以灵活地集成到任何支持自定义提示词的AI编程工具中。下面我将详细说明在不同环境下的配置方法并补充一些原始文档未提及的细节和技巧。3.1 Claude Code 深度集成Claude Code 是目前与这个技能结合最紧密的环境因为它原生支持“技能Skills”目录。标准安装步骤打开终端。执行克隆命令将技能仓库克隆到 Claude Code 的技能目录下git clone https://github.com/designedbysom/accessibility-linter ~/.claude/skills/accessibility-linter完全重启 Claude Code 应用。它会自动扫描~/.claude/skills/目录下的所有文件夹并将其中的技能加载为可用的上下文。进阶配置与排查技能目录位置上述~/.claude/skills/是默认路径。如果你自定义过 Claude Code 的设置需要确认技能的实际加载路径。通常可以在 Claude Code 的设置或官方文档中找到。技能不生效首先检查~/.claude/skills/accessibility-linter/目录下是否存在SKILL.md文件。其次确保重启了 Claude Code不仅仅是关闭窗口最好通过活动监视器或任务管理器确认进程已结束再重启。有时技能加载可能需要几秒钟。多技能管理~/.claude/skills/目录下可以存放多个技能文件夹。Claude Code 会尝试将它们全部加载。如果遇到技能间冲突或提示词过长的问题可能需要手动管理或联系工具方。注意事项在 Claude Code 中技能是全局启用的。这意味着你和 AI 的所有对话都会受到该技能规则的影响。对于纯粹的后端逻辑、数据算法讨论它可能也会“多管闲事”地询问前端可访问性问题。这时你需要清晰地用自然语言设定对话边界例如“我们现在只讨论Python数据处理逻辑不涉及UI。”3.2 Cursor 规则配置Cursor 通过“规则Rules”功能来实现类似效果。规则是项目级别的更具针对性。详细配置流程在 Cursor 中打开你的前端/全栈项目。打开命令面板通常是Cmd/Ctrl Shift P搜索并选择“Cursor: Open Rules Settings”。或者你可以直接导航到项目根目录下的.cursor/rules/文件夹如果不存在需手动创建。在规则设置界面或.cursor/rules/文件夹内创建一个新的.md文件例如a11y-linter.md。打开accessibility-linter项目中的SKILL.md文件将其全部内容复制粘贴到新建的a11y-linter.md中并保存。规则的作用域与优先级项目级生效此规则仅对当前项目中的AI交互生效不影响其他项目。这比 Claude Code 的全局技能更精细。规则组合你可以在.cursor/rules/下放置多个.md文件Cursor 会将其内容组合后作为系统提示词。你可以创建general-code-style.md、react-best-practices.md和这里的a11y-linter.md让AI同时遵循多种约定。文件头指令你可以在规则文件顶部添加特定的注释来微调行为例如!-- context: global --或!-- priority: high --具体语法需参考 Cursor 官方文档。3.3 其他AI工具Claude Projects, Replit, v0等的通用方法对于任何允许你设置系统提示词System Prompt或上传知识库Knowledge Base的AI工具都可以使用此技能。通用集成步骤找到工具的“系统提示词”、“自定义指令”、“代理设置”或“项目知识/上下文”上传区域。将SKILL.md文件的全部内容粘贴进去。通常你还需要用一句简短的指令激活它例如“请始终遵循 attached accessibility linter skill 中的准则进行设计和代码编写。”在不同场景下的微调建议在 Claude Projects 或 ChatGPT 的“自定义指令”中由于字符限制你可能需要提炼SKILL.md的核心原则三层工作模式、核心覆盖领域而不是全文粘贴。重点保留那些“构建前询问”的具体问题示例。在 Replit、v0 等原型工具中这些工具通常用于快速构建UI。集成后当你用自然语言描述一个组件时如“做一个蓝色主题的登录卡片”AI会在生成代码前主动询问关于表单标签、错误状态展示、提交后焦点处理等关键无障碍问题从而从一开始就产出更健壮的代码。作为代码评审的检查清单即使不在AI工具中使用你也可以将EXAMPLE-SCENARIOS.md中的12个真实场景作为团队代码评审Code Review时的参考清单引导评审者关注结构性问题而非仅仅是样式细节。4. 实战场景剖析与交互示例理论需要实践来印证。让我们通过几个扩充后的真实场景来看看accessibility-linter如何具体工作。这些场景超越了简单的代码生成展示了其“设计伙伴”的一面。4.1 场景一构建一个图标按钮用户输入“在React里做一个红色的删除图标按钮。”没有技能干预时AI可能直接生成button onClick{handleDelete} classNamebg-red-500 p-2 rounded TrashIcon / /button这段代码对视觉用户没问题但对屏幕阅读器用户来说按钮没有任何可访问名称。集成accessibility-linter后AI的行为它不会直接给出上述代码。因为它遵循“第一层默认内置”规则。它会生成button onClick{handleDelete} classNamebg-red-500 p-500 p-2 rounded aria-label删除项目 // 自动补充了aria-label TrashIcon / /button并且可能会附带一句说明“已为图标按钮添加了aria-label“删除项目”。请确认‘删除项目’这个标签是否准确描述了此按钮的操作或者您有更具体的标签例如‘删除[项目名称]’”实操心得这里的关键在于它不仅补全了代码还邀请你确认标签的准确性。aria-label“删除”和aria-label“删除用户配置文件”传达的信息粒度是不同的。这促使开发者在编码时思考上下文而不仅仅是完成任务。4.2 场景二设计一个下拉选择器Custom Select用户输入“我需要一个自定义样式的下拉选择框替代原生的select选项有‘北京’、‘上海’、‘广州’。”这是一个复杂的交互组件涉及键盘导航、焦点管理、状态管理。AI在技能影响下可能会在生成代码前进入“第二层构建前询问”模式它可能会提出一系列结构化问题键盘导航模型“这个自定义下拉框的键盘交互您希望完全遵循原生select的行为吗用上下箭头浏览选项Enter或空格选中ESC关闭还是需要自定义”焦点管理“当下拉框展开时焦点应该停留在触发按钮上还是应该移动到下拉选项列表的第一个选项上关闭后焦点应返回到触发按钮吗”ARIA属性“我会为组件添加role“combobox”、aria-expanded、aria-controls和aria-activedescendant。您需要我详细解释每个属性的作用还是直接应用”屏幕阅读器通告“当用户用键盘选择一项时您希望屏幕阅读器立即播报‘已选择[城市名]’还是仅更新值等待用户离开组件后再通告”只有在用户回答了这些核心问题或确认使用默认建议后AI才会生成完整的、包含所有必要无障碍属性的React组件代码可能长达上百行但结构清晰、可直接访问。4.3 场景三处理一个“有意识的偏离”用户输入“在这个全屏图片画廊里用户用左右箭头键切换图片我不希望ESC键意外退出全屏模式。”AI在技能影响下的回应它不会简单地说“好的我会禁用ESC键”。而是会进入“第三层” “我注意到您希望禁用ESC键来退出全屏画廊。这是一个对常规无障碍模式的偏离常规模式下ESC是关闭或退出交互的预期键。权衡说明这样做可以防止误操作但会剥夺键盘用户一个快速退出交互的预期方式。您必须提供另一个清晰、易用的退出机制例如一个始终可见的、可通过键盘Tab键访问的‘关闭’按钮并确保其获得高焦点可见性。 请确认(a) 您已理解此权衡并且 (b) 您将提供一个可靠的替代退出方案。” 在得到用户明确确认后它才会在生成的键盘事件处理代码中添加注释说明禁用ESC是有意为之并确保替代关闭按钮的代码被优先实现。5. 将技能思维融入团队工作流与常见问题accessibility-linter作为一个工具其最大价值在于它灌输的思维模式。即使不直接使用这个技能我们也可以将其理念融入团队。5.1 在传统开发流程中应用“三层检查法”设计评审阶段在Figma或设计稿评审时除了视觉增加“无障碍设计评审”。针对每个交互组件追问对应第一层这个元素的语义是什么是按钮、链接还是装饰对应第二层这个组件的键盘操作模型是怎样的焦点如何移动状态如何变化对应第三层这里的设计是否有意打破了某种常规打破的代价是什么是否有补偿方案代码编写与PR阶段开发者自查在提交代码前将自己想象成这个“linter”。对于每个新增的交互组件自问技能会提出的那些问题。PR模板在Pull Request模板中增加无障碍检查项例如[ ] 所有交互元素都有适当的语义标签或ARIA标签。[ ] 组件支持完整的键盘导航。[ ] 焦点管理逻辑已实现并测试。[ ] 颜色对比度符合WCAG AA标准。[ ] 任何对常规模式的偏离都已记录并经过评审。团队培训将EXAMPLE-SCENARIOS.md中的案例作为内部工作坊的材料进行角色扮演练习让开发者和设计师熟悉这种“即时提问”的评审方式。5.2 常见问题与应对策略Q1: 技能有时会“过度提问”拖慢简单任务的进度。A1这是有意为之的权衡。对于资深开发者确实可能觉得某些基础问题多余。应对策略是在给AI的指令中提供更精确的上下文。例如不要说“加个按钮”而说“加一个具有删除功能的、带图标和aria-label的按钮”。当你表现出对无障碍基础有了解时AI在技能影响下会更倾向于直接应用“第一层”规则减少不必要的询问。这实际上是在训练你提供更严谨的需求描述。Q2: 它生成的代码有时很冗长增加了复杂度。A2可访问的代码天生就比不可访问的代码包含更多信息ARIA属性、事件监听器等。这种“冗长”是必要的精度。你可以封装与抽象将生成的无障碍组件代码保存为可复用的UI组件如AccessibleModal,AccessibleDropdown。下次直接使用组件而非重新生成。关注结构而非字符数冗长的往往是样板代码boilerplate核心业务逻辑并未增加。将其视为一种基础设施投资。Q3: 技能无法覆盖所有WCAG标准是否意味着可以放松其他检查A3绝对不行。这个技能是“安全带”和“安全气囊”而不是全部的汽车安全测试。它专注于预防高发性、结构性的严重事故。你仍然需要使用自动化测试工具在CI/CD流水线中集成如 axe-core、Lighthouse CI等。进行人工辅助技术测试定期使用屏幕阅读器NVDA, VoiceOver和键盘进行关键用户路径测试。邀请残障人士用户测试这是无可替代的环节。Q4: 对于后端API或纯逻辑代码它也会干扰如何关闭A4在Claude Code等全局技能环境中目前没有“一键关闭”某个技能的功能。最佳实践是会话开始时明确边界“接下来的对话我们将只讨论Node.js后端服务的数据库优化不涉及任何前端UI或无障碍话题。”使用项目级规则优先在Cursor这类支持项目级规则的工具中使用这样它只在前端相关项目中生效。我个人在将这种思维引入团队后最深刻的体会是最大的阻力往往不是技术难度而是习惯的改变。一旦团队度过了最初的不适应期开始习惯在“画第一笔”和“写第一行代码”时就思考无障碍问题你会发现后期返工和修复的耗时大大减少代码的整体质量也因为更严谨的思考而得到提升。这不仅仅是做一个更友好的产品也是在构建一个更稳健、更可维护的代码库。