Accessibility Skill: WCAG 2.2 for Web, iOS and Android

What is the accessibility skill?

The accessibility skill is one SKILL.md in the ECC repository. It tells an AI coding agent to design, implement and audit interfaces against WCAG 2.2 level AA, so screen reader, switch control and keyboard users can perceive and operate them.

The folder this page links to lives under docs/ja-JP, so its prose is Japanese. The code samples and ARIA attributes inside it are in English. The wider ECC repository lists 293 skills.

The five step workflow

• Identify the component role first, and prefer the most semantic native element before a custom role.
• Define perceivable attributes: text contrast, text alternatives for images and icons, and reflow at up to 400 percent zoom.
• Implement operable controls: a minimum target size, keyboard reach, a visible focus indicator and a single pointer option for dragging.
• Ensure understandable logic: consistent navigation, descriptive error messages and no asking for the same data twice.
• Verify compatibility with assistive technology: a correct name, role and value for each control, plus aria-live regions for dynamic status updates.

One requirement, three platforms

• Primary label: aria-label or a label element on the web, accessibilityLabel in SwiftUI, contentDescription in Compose.
• Secondary hint: aria-describedby, accessibilityHint, or a semantics stateDescription.
• Live updates: aria-live polite, accessibilityLiveRegion polite, or a Polite liveRegion mode.
• For platform design guidance beyond accessibility, see iOS design and Android design.

Anti-patterns the skill names

• A div or span used as a button without a role and keyboard support.
• Meaning carried by color alone, such as turning a border red to signal an error.
• A modal that does not contain focus, or cannot be left with Escape or a close button.
• Alt text that starts with Image of or Picture of, which screen readers already announce.

Who the accessibility skill is for

Best for

• Writing component specs for web, iOS and Android from one set of accessibility rules.
• Reviewing existing UI code for WCAG 2.2 gaps such as target size and focus appearance.
• Teams already adopting ECC, since the skill arrives with the full plugin.

Not for

• Installing one skill on its own through the guided setup, which installs the ecc@ecc plugin. The README also shows a selective install with profile and capability flags, but its example does not name this skill.
• A scored compliance report. The SKILL.md gives steps and a checklist, not a rating.
• Readers who need English text. See also accessibility-compliance.

Use it with UiChemy

Use the skill to specify labels, focus and target sizes on a design or build first. When you bring a Figma design into WordPress with UiChemy Figma to WordPress, recheck the result by keyboard. Click Get Started on uichemy.com. See also fixing-accessibility.

How to install Accessibility Skill: WCAG 2.2 for Web, iOS and Android

npx [email protected] setup

1. Check the prerequisites

   The README says the universal package needs Node.js 18 or newer. Plugin setup also needs Git and Claude Code 2.1 or newer on your PATH.

2. Run the guided setup

   Run npx [email protected] setup. The wizard inventories the official marketplace and every Claude install scope, then installs or updates the ecc@ecc plugin in the scope you choose.

3. Pick scope and hooks

   For a typical personal setup the README suggests Global user scope with Standard hooks, then confirm. Rerun the same command later to update or change scope.

4. Start a new session

   Open a fresh Claude Code session, then ask the agent to define or audit a component against WCAG 2.2 using the accessibility skill.

Check that it loaded

In a new Claude Code session run /plugin list and confirm ecc@ecc is enabled. Then ask the agent to audit one component and check it cites WCAG 2.2 criteria and the checklist.

Read the official instructions on GitHub

Key features

• WCAG 2.2 level AA focusThe skill description targets WCAG 2.2 level AA for inclusive products, with semantic ARIA for the web and accessibility traits for iOS and Android.
• POUR as the frameCore concepts are the POUR principles, semantic mapping, the accessibility tree, focus management and labeling with hints through aria-label, accessibilityLabel and contentDescription.
• Five step how-it-worksIdentify the role, define perceivable attributes, implement operable controls, ensure understandable logic, then verify a correct Name, Role, Value pattern.
• Contrast and reflow targetsText contrast of 4.5:1 for normal text and 3:1 for large text and UI, plus content that reflows at up to 400 percent zoom without losing function.
• Target size and focusA minimum 24x24 CSS pixel target (SC 2.5.8), keyboard reach with a visible focus indicator (SC 2.4.11) and a single pointer alternative to dragging.
• Forms that explain themselvesDescriptive error messages with suggestions (SC 3.3.3) and redundant entry prevention (SC 3.3.7), so users never retype data they already gave.
• Cross platform mapping tableA table maps label, hint, action role and live update from HTML and ARIA to SwiftUI modifiers and Compose semantics.
• Three code examplesAn accessible web search form, an iOS delete button with label, hint and trait, and an Android Switch with a content description.
• Checklist and anti-patternsA best practice checklist covers 24x24px web targets, 44x44pt native targets, focus return from menus and labeled icon buttons, next to four named anti-patterns.

Frequently asked questions