Accessibility engineering

Skill vignesh2027/AI-AGENT-SKILLS/skills/accessibility-engineering

Turn your ai agent into senior engineer..The result is fast code that fails slowly. AI Agent Skills solves this by giving agents the same disciplined workflows senior engineers use

Install

npx -y skills add vignesh2027/AI-AGENT-SKILLS --skill accessibility-engineering

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Build UIs that work for all users including keyboard navigation, screen readers, and WCAG 2.2

SKILL.md

2.9 KB, as published. Nobody here has run it

Overview

Accessibility is not a checklist — it is a commitment to not excluding users. 1 in 4 adults has some form of disability. Inaccessible software is defective software. This skill bakes accessibility in during development, not as a retrofit.

When to Use

Before implementing any UI component
Before any UI is marked complete
As part of the /review workflow for frontend changes

Process

Step 1: Semantic HTML first

Use the right HTML elements before reaching for ARIA:

Buttons for actions (<button>), links for navigation (<a href>)
Headings for document structure (<h1>–<h6> in correct order)
Lists for lists (<ul>, <ol>)
Form labels associated with inputs (<label for>)
Landmark regions (<nav>, <main>, <header>, <footer>, <aside>)

ARIA only when native semantics are insufficient.

Step 2: Keyboard navigation

Every interactive element must be:

Reachable by Tab
Activatable by Enter/Space
Part of a logical tab order
Visually focused (:focus-visible style)
Not trapped in a dead end (modals must trap focus; must release on close)

Test: complete the key user journeys using only the keyboard.

Step 3: Screen reader testing

Test with at least one screen reader:

VoiceOver (macOS/iOS) + Safari
NVDA or JAWS (Windows) + Chrome
TalkBack (Android)

Verify: can a screen reader user complete the same tasks as a sighted user?

Step 4: Color and contrast

Text contrast ratio: ≥ 4.5:1 for normal text, ≥ 3:1 for large text (WCAG AA)
Do not convey information by color alone (use icons, patterns, text)
Test in grayscale mode

Step 5: Dynamic content

Announce dynamic updates with aria-live regions
Focus management after navigation (move focus to new content)
Loading states must be communicated to screen readers
Errors must be associated with their form fields

Step 6: Images and media

All meaningful images have descriptive alt text
Decorative images have alt=""
Videos have captions and transcripts
Audio content has transcripts

Step 7: Motion and animation

Respect prefers-reduced-motion
No flashing content above 3Hz (seizure risk)
Animation should not distract or interfere with content

Step 8: Automated testing

Run axe-core, Lighthouse, or WAVE on every page. Automate in CI. These catch ~30–40% of accessibility issues.

Verification Requirements

Semantic HTML used (not <div> for everything)
All user journeys completable by keyboard only
Tested with a screen reader
Color contrast ratios meet WCAG AA
Dynamic updates announced
All images have appropriate alt text
Reduced motion respected
Automated accessibility tests pass in CI