Back to Details

experience-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规则存在直接关联，明确违反该准则时，才可标记为违规。

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.
  1. 仅聚焦无障碍性：
    • 仅针对无障碍性评估组件。
    • 只考量是否符合所引用的WCAG成功准则，忽略归因于其他准则的违规情况。
    • 避免处理与无障碍无关的通用代码风格、模式或问题。
  2. 确保最低且充分的无障碍性：
    • 识别阻碍组件达到WCAG最低要求的无障碍问题。
    • 除非绝对必要，否则不建议超出WCAG合规范围的增强措施。
  3. WAI-ARIA使用规范：
    • 仅当语义化HTML无法实现无障碍需求时，才严格使用WAI-ARIA属性。
    • 避免因错误使用或过度使用ARIA属性导致不必要的复杂度或潜在的回归问题。
  4. 组件库使用说明：
    • 假设知名组件库（如Salesforce Lightning、Material UI、Chakra UI）在正确实现的情况下默认具备无障碍性。除非这些组件的使用方式明确违反WCAG，否则在本次审查中可忽略库提供的组件，因为它们在抽象层之下已按无障碍标准实现。
核心目标：提供可执行的反馈，确保组件满足必要的WCAG无障碍要求，避免提供与提示范围无关的额外反馈。仅当存在即时修复方案时，才识别代码中的问题。您必须完成审查，并随后提出解决该问题的代码修复建议。

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)
确定哪些成功准则适用于待审查的代码，然后打开与该代码相关的参考文件。每个参考文件都是一个独立的审查器，包含分析框架、示例和修复指导。

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 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 对比度（最低要求）

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 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 拖拽操作

Robust

可理解性

  • SC 4.1.2 (i) Name
  • SC 4.1.2 (ii) Role
  • SC 4.1.2 (iii) Value
  • SC 3.2.1 获取焦点时
  • SC 3.2.2 输入时
  • SC 3.3.1 错误识别
  • SC 3.3.2 标签或说明
  • SC 3.3.3 错误建议

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)
  • SC 4.1.2 (i) 名称
  • SC 4.1.2 (ii) 角色
  • SC 4.1.2 (iii) 值

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.
当有组件截图或设计原型可用时，可结合这些视觉层面的审查器补充源代码审查。每个参考文件涵盖对应成功准则的基于图像的评估——包括对比度、颜色依赖、缩放/回流行为，以及从像素而非DOM识别非文本内容。
  • SC 1.1.1 非文本内容（视觉）
  • SC 1.4.1 颜色使用（视觉）
  • SC 1.4.3 对比度（视觉）
  • SC 1.4.10 回流（视觉）
  • SC 1.4.11 非文本对比度（视觉）
—

审查输出

—
针对您评估的每一项成功准则，报告发现的违规情况。如果某准则未发现违规，则返回空列表。