# Universal Accessibility Wcag > Use for ANY UI change — every component, page, form, image, color choice, interaction, or content block — to make it conform to WCAG 2.2 Level AA (and AAA where feasible) so it is usable by people with visual, motor, auditory, cognitive, and speech disabilities, using a keyboard, screen reader, magnifier, or voice. Covers semantic HTML first, ARIA done correctly, keyboard and focus management, color/contrast, accessible forms and error handling, media alternatives, and automated + manual accessibility testing wired into CI. Trigger proactively on forms, inputs, labels, images, alt text, icons, buttons, modals/dialogs, menus, tabs, color, contrast, focus, keyboard, tab order, ARIA, roles, screen reader, "a11y," accessible, WCAG, Section 508, ADA — even without those words, on any code that renders UI. - Skill: `techfleetworks/universal-accessibility-wcag` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add techfleetworks/universal-accessibility-wcag` - Raw SKILL.md: https://api.skillmd.com/api/skills/techfleetworks/universal-accessibility-wcag/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: techfleetworks (https://skillmd.com/u/techfleetworks) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/techfleetworks/universal-accessibility-wcag --- # Universal Accessibility (WCAG Conformance) ## Why this exists Roughly one in six people lives with a disability. Every UI you ship is used by people who are blind or low-vision, who can't use a mouse, who are deaf or hard of hearing, who have limited dexterity or tremor, who have cognitive or attention differences, or who are simply in a hard situation (bright sun, one hand full, a noisy room). Accessibility isn't a feature for a minority — it's the difference between "everyone can use this" and "some people are locked out." It is also, in most jurisdictions, a **legal requirement** (ADA, Section 508, EN 301 549, the European Accessibility Act), and it is far cheaper to build in than to retrofit. This skill's bar is **WCAG 2.2 Level AA conformance, verified** — not "we tried to make it accessible." Accessibility is a property you *build and test*, the same way you build and test correctness. ## The core principle **Semantic HTML first; ARIA only to fill genuine gaps; then verify with automation, the keyboard, and a screen reader.** The vast majority of accessibility comes free from using the right native element. ARIA is a supplement for custom widgets, and *bad ARIA is worse than none*. Nothing is "accessible" until it has been operated without a mouse and heard through a screen reader. Organize everything around WCAG's four principles — **POUR**: Perceivable, Operable, Understandable, Robust. If content fails any one, someone is excluded. ## The workflow ### Step 1: Know the target — WCAG 2.2 AA and POUR Read `references/wcag-principles-and-conformance.md`. Understand the conformance target (Level **AA** is the standard bar; **A** is the floor; **AAA** where feasible), the four POUR principles, and the success criteria most changes touch. Every review below maps to specific success criteria — cite them so "accessible" is concrete, not vibes. ### Step 2: Build on semantic HTML Read `references/semantic-html-and-aria.md`. Before any ARIA: - Use the **native element** for the job: `