Back to Details

experience-lwc-accessibility-validate

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<!-- adk-managed-skill -->
<!-- adk-managed-skill -->

Web Component Accessibility

Web组件可访问性

Accessibility (a11y) patterns and remediation guidance for web components. Reference any time work involves the visible or interactive surface of a component — generating, modifying, reviewing, or styling HTML, JS, or CSS — to apply WCAG 2.2 standards.
Web组件的可访问性（a11y）模式与修复指南。 每当工作涉及组件的可见或交互层面——生成、修改、审查或编写HTML、JS或CSS时，均可参考此指南以遵循WCAG 2.2标准。

Review Context

审查背景

Conduct a review specifically focused on enhancing web accessibility, guided by the WCAG (Web Content Accessibility Guidelines).
In order to mark code as a violation, it must have a direct correlation to the WCAG rule cited such that it is a clear violation of the criteria.
Key Review Criteria:
  1. Focus Exclusively on Accessibility:
  • Evaluate the component solely for accessibility.
  • Only consider compliance with the cited WCAG Success Criteria, ignoring violations that can be attributed to other criteria.
  • Avoid addressing general code style, patterns, or issues unrelated to accessibility.
  1. Ensure Minimum and Sufficient Accessibility:
  • Identify accessibility issues that prevent the component from meeting the minimum requirements outlined by WCAG.
  • Avoid suggesting enhancements that go beyond the scope of WCAG compliance unless strictly necessary.
  1. WAI-ARIA Usage:
  • Use WAI-ARIA attributes only when strictly required to achieve accessibility that cannot otherwise be addressed with semantic HTML.
  • Avoid unnecessary complexity or potential regressions caused by incorrect or overuse of ARIA attributes.
  1. Component Library Usage
  • Assume that well-known component libraries (e.g., Salesforce Lightning, Material UI, Chakra UI) are accessible out of the box when correctly implemented. Unless they are used specifically in conflict with WCAG, library-provided components can be ignored for this review, as they are implemented in an accessible way beneath the abstraction.
Focus: Provide actionable feedback to ensure the component meets the necessary WCAG accessibility requirements, avoiding extraneous feedback unrelated to the prompt's scope. Identify issues in code only if there is an immediate fix. You MUST conduct the review, and subsequently suggest the code fix that solves this issue.
以WCAG（Web内容无障碍指南）为指导，专门开展聚焦于提升Web可访问性的审查。
只有当代码与引用的WCAG规则存在直接关联，明确违反准则时，才能标记为违规。
核心审查标准：
  1. 仅聚焦于可访问性：
  • 仅针对可访问性评估组件。
  • 仅考量是否符合引用的WCAG成功准则，忽略可归因于其他准则的违规情况。
  • 避免处理与可访问性无关的通用代码风格、模式或问题。
  1. 确保最低且充分的可访问性：
  • 识别阻碍组件达到WCAG规定最低要求的无障碍问题。
  • 除非绝对必要，避免提出超出WCAG合规范围的增强建议。
  1. WAI-ARIA使用规范：
  • 仅在无法通过语义化HTML实现可访问性时，才严格使用WAI-ARIA属性。
  • 避免因不正确或过度使用ARIA属性导致不必要的复杂性或潜在的回归问题。
  1. 组件库使用
  • 假设知名组件库（如Salesforce Lightning、Material UI、Chakra UI）在正确实现时本身具备可访问性。除非这些组件的使用明确违反WCAG，否则在本次审查中可忽略库提供的组件，因为它们在抽象层之下已以无障碍方式实现。
重点：提供可操作的反馈，确保组件满足必要的WCAG无障碍要求，避免提供与提示范围无关的额外反馈。仅在有即时修复方案时才识别代码中的问题。你必须开展审查，并随后提出解决该问题的代码修复建议。

Success Criteria Reviewers

成功准则审查器

Identify which Success Criteria apply to the code under review, then open the reference files relevant to that code. Each reference is a self-contained reviewer with analysis framework, examples, and remediation guidance.
确定哪些成功准则适用于待审查的代码，然后打开与该代码相关的参考文件。每个参考文件都是一个独立的审查器，包含分析框架、示例和修复指南。

Perceivable

可感知性

  • SC 1.1.1 Non-text Content
  • SC 1.3.1 (i) Lists
  • SC 1.3.1 (ii) Tables
  • SC 1.3.1 (iii) Form Labels
  • SC 1.3.1 (iv) Regions
  • SC 1.3.1 (v) Groups
  • SC 1.3.5 Identify Input Purpose
  • SC 1.4.3 Contrast (Minimum)
  • 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 对比度（最低要求）

Operable

可操作性

  • SC 2.1.1 Keyboard
  • SC 2.4.4 Link Purpose
  • SC 2.4.6 Headings and Labels
  • SC 2.5.1 Pointer Gestures
  • SC 2.5.2 Pointer Cancellation
  • SC 2.5.3 Label in Name
  • SC 2.5.7 Dragging Movements
  • 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 拖拽操作

Understandable

可理解性

  • SC 3.2.1 On Focus
  • SC 3.2.2 On Input
  • SC 3.3.1 Error Identification
  • SC 3.3.2 Labels or Instructions
  • SC 3.3.3 Error Suggestion
  • SC 3.2.1 获取焦点时
  • SC 3.2.2 输入时
  • SC 3.3.1 错误识别
  • SC 3.3.2 标签或说明
  • SC 3.3.3 错误建议

Robust

健壮性

  • SC 4.1.2 (i) Name
  • SC 4.1.2 (ii) Role
  • SC 4.1.2 (iii) Value
  • SC 4.1.2 (i) 名称
  • SC 4.1.2 (ii) 角色
  • SC 4.1.2 (iii) 值

Vision-Assisted Review

视觉辅助审查

When component screenshots or design mocks are available, augment the source-code review with these vision-level reviewers. Each reference covers image-based evaluation for the corresponding Success Criterion — contrast ratios, color dependence, resize/reflow behavior, and non-text content identification from pixels rather than from the DOM.
  • SC 1.1.1 Non-text Content (vision)
  • SC 1.4.1 Use of Color (vision)
  • SC 1.4.3 Contrast (vision)
  • SC 1.4.10 Reflow (vision)
  • SC 1.4.11 Non-text Contrast (vision)
当有组件截图或设计原型时，可在源代码审查的基础上结合这些视觉层面的审查器。每个参考文件涵盖对应成功准则的基于图像的评估——对比度、颜色依赖、缩放/重排行为，以及从像素而非DOM识别非文本内容。
  • SC 1.1.1 非文本内容（视觉）
  • SC 1.4.1 颜色使用（视觉）
  • SC 1.4.3 对比度（视觉）
  • SC 1.4.10 重排（视觉）
  • SC 1.4.11 非文本对比度（视觉）

Review Output

审查输出

For each Success Criterion you evaluated, report violations found. If no violations exist for a criterion, return an empty list for that criterion.
对于每个评估的成功准则，报告发现的违规情况。如果某准则无违规，则返回空列表。