无障碍设计（Accessibility，常缩写为a11y）长期处在一个尴尬的位置：大家都知道它重要，但在实际排期中往往被排在最后，甚至直接被砍掉。随着大模型能力提升，用自然语言驱动模型对界面和代码做无障碍检查，成了一个人人可上手的低成本方案。本文将介绍如何设计高质量的检查类Prompt，覆盖WCAG原则拆解、结构化模板、具体场景检查指令，以及这套方法的边界在哪里。
一、把WCAG原则翻译成模型能执行的语言
多数人写无障碍检查Prompt时容易犯一个错误：直接丢一句“帮我检查一下这个页面有没有无障碍问题”。这种指令太模糊，模型只能给出泛泛而谈的回答。真正有效的做法是先把WCAG 2.x的核心原则拆开，再逐条转化为可执行的检查任务。WCAG的四条原则常被概括为POUR：可感知（Perceivable）、可操作（Operable）、可理解（Understandable）、健壮性（Robust）。
对应到提示词层面，你需要为每条原则写出具体的检查项。例如“可感知”可以拆解为：图片是否有替代文本、颜色对比度是否达标、除颜色外是否有其他视觉线索；“可操作”可以拆解为：所有交互元素能否通过键盘访问、焦点顺序是否合理、是否有键盘陷阱。拆得越细，模型的输出越接近一份可用的检查报告。
一个实用技巧是在Prompt中直接引用WCAG条款编号，比如“对照WCAG 2.1 AA级的1.4.3（最低对比度4.5:1）检查以下CSS颜色组合”。模型对标准文档的训练语料相当充分，给出明确条款号能让回答的准确度明显提升，同时减少模型自己“发明标准”的概率。
二、结构化Prompt模板的设计方法
单轮提问适合快速排查，但如果你希望输出稳定、可复用，就需要一个结构化模板。推荐的角色-任务-标准-输出格式四段式结构，在无障碍检查场景中效果很好。下面是一个可以直接复用的模板：
你是一名资深的无障碍设计专家，熟悉WCAG 2.1 AA级标准。 任务：对我提供的HTML代码进行无障碍检查。 检查范围： 1. 语义化标签使用是否正确 2. 图片是否都有有意义的alt文本 3. 表单控件是否有关联的label 4. 标题层级是否连续 5. 键盘可访问性相关的属性是否完备 输出格式： 按以下结构输出每一处问题： - 问题描述 - 违反的WCAG条款 - 严重程度（高/中/低） - 具体修复建议（附修改后的代码片段） 以下是待检查的代码： （粘贴HTML代码）
这个模板的关键在于“输出格式”部分。没有约束时，模型倾向于输出一段流畅但难以落地的总结；明确要求逐条列出问题、条款、严重程度和修复代码后，输出就变成了一份可以直接丢进任务管理系统的修复清单。
另一个容易被忽略的技巧是分批检查。一次性贴入上千行代码，模型的注意力会被稀释，靠后的问题往往被漏掉。更好的做法是按组件拆分：先查导航，再查表单，再查弹窗。每次只针对一个组件，配合针对性指令，比如“只检查这个模态框的焦点管理”，检出率会高得多。
三、典型场景的检查指令与示例
不同类型的无障碍问题需要不同的检查侧重点。颜色对比度是最常见的重灾区，你可以在Prompt中提供设计稿的色值或CSS变量，让模型逐对计算对比度比值：
请检查以下颜色组合是否满足WCAG 2.1 AA级要求： - 正文文字对比度至少4.5:1，大号文字至少3:1 - 对每一对前景色/背景色，给出计算出的对比度比值 - 不达标的组合给出调整建议色值 颜色组合： 1. 文字 #999999，背景 #FFFFFF 2. 按钮 #FF5722，文字 #FFFFFF 3. 链接 #1E88E5，背景 #FAFAFA
针对前端代码的检查，重点应放在语义和交互属性上。一个值得用的指令是让模型扮演屏幕阅读器用户，逐元素描述它“听到”的内容，这样能快速暴露出缺少替代文本、label未关联、动态更新无提示等问题。比如：
<!-- 待检查的典型问题代码 --> <div class="btn" onclick="submit()">提交</div> <input type="text" name="phone"/> <img src="chart.png"/>
这三行代码集中了三个经典问题：<div>模拟按钮导致键盘无法操作，输入框没有关联label导致屏幕阅读器不知道要填什么，图片缺少alt属性导致图表信息完全丢失。好的Prompt应该要求模型按“现象-影响-修复”三层展开，而不是简单说“这里有问题”。修复后的版本可以要求模型直接给出：
<button type="button" onclick="submit()">提交</button> <label for="phone">手机号</label> <input type="tel" id="phone" name="phone" aria-required="true"/> <img src="chart.png" alt="2024年季度销售额柱状图，第四季度环比增长23%"/>
除了代码层面，文案层面的包容性检查也很有价值。你可以让模型审查界面文案中是否存在性别刻板印象、地域性俚语、对残障人群不恰当的表述，或者是否使用了过于专业的术语而缺少解释。这类检查几乎没有现成工具能做，恰恰是大模型的强项。
四、纯Prompt检查的局限与落地建议
必须承认，大模型做无障碍检查有明确的能力边界。第一，它无法真实渲染页面，对比度、焦点顺序这类依赖实际布局的问题只能基于代码推断，存在误报和漏报。第二，它无法替代真实用户测试——屏幕阅读器的实际体验、认知障碍用户的操作习惯，这些只有真人测试才能发现。第三，模型对上下文长度的限制意味着大型项目只能抽查。
因此合理的定位是：把Prompt检查作为流程的第一道筛子，后面接上axe、Lighthouse等自动化工具做精确扫描，关键路径再辅以人工测试。三者的关系是互补而非替代——模型擅长理解意图和上下文（比如判断一段alt文本写得是否描述到位，这是工具做不到的），工具擅长精确计算（比如像素级对比度），用户测试擅长发现真实体验问题。
落地时有两条建议：一是把检查Prompt沉淀为团队共享的模板，配合代码评审流程使用，每次PR自动附带一份a11y检查输出；二是要求模型输出的每条问题都标注严重程度和修复代码，这样检查结果能直接转化为开发任务，而不是停留在报告层面。无障碍的本质是让所有人都能用你的产品，大模型降低的正是这件事的启动成本——先让检查跑起来，再逐步完善流程。