用途
该技能用于判断 Lightning Web Component（LWC）是否具备无障碍性并符合 WCAG 无障碍指南。当用户询问组件是否可访问时触发。它提供 Web 组件的无障碍（a11y）模式与修复指导，适用于任何涉及组件可见或交互界面的工作——生成、修改、审查或样式化 HTML、JS 或 CSS——以应用 WCAG 2.2 标准。
主要能力
审查专门聚焦于提升 Web 无障碍性，以 WCAG（Web 内容无障碍指南）为指导。要将代码标记为违规，必须与所引用的 WCAG 规则有直接关联，构成对标准的明确违反。
关键审查标准：
- 完全聚焦无障碍：仅从无障碍角度评估组件；只考虑所引用的 WCAG 成功标准的合规性，忽略可归因于其他标准的违规；避免处理与无障碍无关的一般代码风格、模式或问题。
- 确保最小且充分的无障碍：识别阻止组件满足 WCAG 最低要求的问题；除非严格必要，避免提出超出 WCAG 合规范围的增强建议。
- WAI-ARIA 使用：仅在语义 HTML 无法实现无障碍时才严格使用 WAI-ARIA 属性；避免因错误或过度使用 ARIA 属性造成不必要的复杂性或潜在回归。
组件库使用：假定知名组件库（如 Salesforce Lightning、Material UI、Chakra UI）在正确实现时开箱即用。除非它们的使用与 WCAG 冲突，否则库提供的组件可在此审查中忽略，因为它们在抽象层之下以无障碍方式实现。
Lightning 基础组件（lightning-input、lightning-combobox、lightning-textarea、lightning-icon 等）通过 label、alternative-text 等专用属性提供无障碍标签、ARIA 和错误处理。即使 variant="label-hidden"，标签仍是程序化的；不要要求同级或包裹的 <label> 来指向该组件。导航、button-icon 及其他自标记基础组件同样将提供的标签文本作为其无障碍名称，并将其内部图标视为装饰性。不要仅因该实现隐藏在组件内部就报告缺少关联。
同样的自标记逻辑适用于任何框架（React/JSX、Angular、Vue、Web Components）中导入或自定义的控件组件，不仅限于 Lightning。大写或导入的组件标签（<Input>、<TextField>、<Button>、<Select>、<Checkbox>、<SearchField> 以及来自 Material UI、Chakra、Radix 或内部库的设计系统包装器）不是裸 HTML 元素——假定其在抽象层之下渲染自己的无障碍标签、ARIA 和错误处理（见组件库基础规则）。当此类组件被赋予标签属性——label、aria-label、aria-labelledby、title 或可见的子文本/children——视为已程序化标记，不要因其缺少 <label>、缺少 for/id 关联或缺少无障碍名称而标记。仅当未提供标签属性或文本，或提供的值明显为空或无意义时才标记。不要为看不到内部控件的组件要求原生 <label for>。
在判断标签关联前解析动态 id / htmlFor / for 表达式。当 <label htmlFor={X}>（或 for={X}）与其控件的 id={X} 绑定到同一表达式——同一变量、prop、useId() 值或模板字面量（例如 htmlFor 和 id 都设为同一插值如 ${id}-email）——即使审查时无法解析字面字符串，也视为关联匹配。动态 id/htmlFor 对仅在两个表达式明显不同时才是不匹配。不要将相同的动态 id/htmlFor 表达式标记为未匹配或不匹配的标签。
使用方式
源解释：在判断表达式前，按框架的绑定语义解析表达式。将动态值追溯到该上下文中所有可用来源。在 React/JSX 中，表达式可引用局部变量、props、hook 结果或导入绑定；Vue、Svelte 和 Astro 暴露各自的模板或脚本作用域。在 LWC 模板中，{someValue} 解析为组件类（.js 或 .ts）上的字段、属性或 getter，包括 @api 属性；模块级导入常量不可直接绑定。在 Aura 标记中，遵循表达式的值提供者（如 v. 或 c.）到相应组件属性或控制器逻辑。在检查适用来源之前，不要断定值为 undefined、空或缺失。在 diff 中，验证哪一侧包含修正后的代码，而不是假定更改引入了问题。
重点：提供可操作的反馈，确保组件满足必要的 WCAG 无障碍要求，避免与提示范围无关的多余反馈。仅当存在即时修复时才识别代码中的问题。必须执行审查，并随后建议解决该问题的代码修复。
成功标准审查者：确定哪些成功标准适用于所审查的代码，然后打开与该代码相关的参考文件。每个参考提供特定标准的分析、示例和修复指导；上述审查范围规则继续适用。
可感知：SC 1.1.1 非文本内容；SC 1.3.1 (i) 列表；SC 1.3.1 (ii) 表格；SC 1.3.1 (iii) 表单标签；SC 1.3.1 (iv) 区域；SC 1.3.1 (v) 分组；SC 1.3.5 识别输入目的；SC 1.4.3 对比度（最低）。
可操作：SC 2.1.1 键盘；SC 2.4.4 链接目的；SC 2.4.6 标题和标签；SC 2.5.1 指针手势；SC 2.5.2 指针取消；SC 2.5.3 名称中的标签；SC 2.5.7 拖动移动。
可理解：SC 3.2.1 聚焦时；SC 3.2.2 输入时；SC 3.3.1 错误识别；SC 3.3.2 标签或说明；SC 3.3.3 错误建议。
健壮：SC 4.1.2 (i) 名称；SC 4.1.2 (ii) 角色；SC 4.1.2 (iii) 值。
视觉辅助审查：当组件截图或设计稿可用时，用这些视觉级审查者增强源代码审查。每个参考涵盖对应成功标准的基于图像的评估——对比度、颜色依赖、调整大小/重排行为，以及从像素而非 DOM 识别非文本内容。包括：SC 1.1.1 非文本内容（视觉）；SC 1.4.1 颜色的使用（视觉）；SC 1.4.3 对比度（视觉）；SC 1.4.10 重排（视觉）；SC 1.4.11 非文本对比度（视觉）。
审查输出：对于所评估的每个成功标准，报告发现的违规。如果某标准不存在违规，则为该标准返回空列表。
适用场景
适用于涉及组件可见或交互界面的生成、修改、审查或样式化 HTML、JS 或 CSS 的工作，尤其是需要依据 WCAG 2.2 标准评估 LWC 无障碍性的场景。
限制
审查仅聚焦无障碍，不处理一般代码风格或与无障碍无关的问题；仅识别有即时修复的问题；不提出超出 WCAG 合规范围的增强建议；假定知名组件库在正确实现时开箱即用。关于收费、价格、平台支持等具体信息暂未提供。