How do I install the Frontend A11Y skill?

Run npx skillmds@latest add tmj-90/frontend-a11y in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Frontend A11Y safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Frontend A11Y?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Frontend A11Y free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Frontend A11Y?

tmj-90 (@tmj-90) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Frontend A11Y by tmj-90 — Agent Skill

Name: Frontend A11Y
Author: tmj-90

Frontend A11Y

Use when a ticket requires accessibility work or when delivering UI that must be usable by everyone — keyboard navigation, screen-reader labelling, focus management, colour contrast, or reduced-motion support. Invoke for "make X accessible", "fix the a11y issues", "add keyboard support", or as a companion check on any new component.

tmj-90 9887868 2.4 KB Updated Sep 17, 2026

File contents

Make the UI accessible

Bring the affected UI to WCAG 2.2 AA: operable by keyboard, understandable to assistive tech, and tolerant of user preferences — proven, not assumed.

Steps

Read the lore first. Call search_lore (Memory MCP) for the repo's accessibility conventions and any design-system a11y primitives already in use.
Use semantic HTML before ARIA. Reach for the native element (button, a, label, nav, dialog) first; add ARIA roles/attributes only to fill real gaps.
Make it keyboard operable. Every interactive element must be focusable and activatable by keyboard, in a logical tab order, with a visible focus indicator.
Label everything. Associate inputs with labels, give icon-only controls an accessible name, and announce dynamic changes with live regions where needed.
Manage focus for overlays/dialogs/menus: move focus in on open, trap it while open, restore it on close.
Respect preferences. Honour prefers-reduced-motion; ensure text/background contrast meets AA (4.5:1 body, 3:1 large text).
Verify + evidence. Run the repo's automated a11y checks and exercise keyboard flow; record the results via the record-evidence skill and submit for review.

Rules

Native semantics over ARIA; never use ARIA to paper over the wrong element.
No keyboard trap, no focus loss, no invisible focus.
Don't remove focus outlines without a compliant replacement.
Colour is never the only signal — pair it with text or icon.

Capture lore

This skill is one of the places durable, reusable knowledge naturally surfaces: An accessibility pattern or boundary this repo standardises on — a focus-management rule, a semantics convention, or an a11y check that must pass. That kind of fact is lore. Capture it via the lore-capture protocol in your brief (CLAUDE.factory.md, step 11 "Memory contribution"): call the Memory MCP suggest_lore once at the close of your work — reusable conventions, gotchas, decisions, and boundaries only, never per-ticket trivia.

---name: frontend-a11ydescription: Use when a ticket requires accessibility work or when delivering UI that must be usable by everyone — keyboard navigation, screen-reader labelling, focus management, colour contrast, or reduced-motion support. Invoke for "make X accessible", "fix the a11y issues", "add keyboard support", or as a companion check on any new component.---# Make the UI accessibleBring the affected UI to WCAG 2.2 AA: operable by keyboard, understandable toassistive tech, and tolerant of user preferences — proven, not assumed.## Steps1. **Read the lore first.** Call `search_lore` (Memory MCP) for the repo's accessibility conventions and any design-system a11y primitives already in use.2. **Use semantic HTML before ARIA.** Reach for the native element (`button`, `a`, `label`, `nav`, `dialog`) first; add ARIA roles/attributes only to fill real gaps.3. **Make it keyboard operable.** Every interactive element must be focusable and activatable by keyboard, in a logical tab order, with a visible focus indicator.4. **Label everything.** Associate inputs with `label`s, give icon-only controls an accessible name, and announce dynamic changes with live regions where needed.5. **Manage focus** for overlays/dialogs/menus: move focus in on open, trap it while open, restore it on close.6. **Respect preferences.** Honour `prefers-reduced-motion`; ensure text/background contrast meets AA (4.5:1 body, 3:1 large text).7. **Verify + evidence.** Run the repo's automated a11y checks and exercise keyboard flow; record the results via the `record-evidence` skill and submit for review.## Rules- Native semantics over ARIA; never use ARIA to paper over the wrong element.- No keyboard trap, no focus loss, no invisible focus.- Don't remove focus outlines without a compliant replacement.- Colour is never the only signal — pair it with text or icon.## Capture loreThis skill is one of the places durable, reusable knowledge naturally surfaces:**An accessibility pattern or boundary this repo standardises on — a focus-management rule, a semantics convention, or an a11y check that must pass.** That kind of fact is *lore*. Capture it via the **lore-captureprotocol in your brief** (`CLAUDE.factory.md`, step 11 "Memory contribution"):call the Memory MCP `suggest_lore` once at the close of your work — reusableconventions, gotchas, decisions, and boundaries only, never per-ticket trivia.

Frequently asked questions