agentleFS
wdm0006wdm0006/python-skills/skills/common/accessible-interfaces/SKILL.md

building-accessible-interfaces

Skill111 starsChanged 18 days agoMITView on GitHub

Makes web and app UIs usable by keyboard, screen-reader, low-vision and motion-sensitive users — semantic HTML before ARIA, labelled controls, visible focus, WCAG AA contrast measured rather than eyeballed, touch targets, reduced motion, and automated axe checks plus a manual keyboard pass in CI or before every UI PR. Use when building or restyling a screen, adding a form, modal, menu or custom control, choosing colors, or reviewing a UI change.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Every interactive element is reachable, in visual order, with a visible focus indicator.

    line 54
  2. Distinctive:

    Add a "Skip to content" link as the first focusable element on content-heavy pages.

    line 61
  3. Very specific:

    No keyboard traps; no tabindex greater than 0.

    line 62
  4. Distinctive:

    Do not auto-advance carousels or time out forms without a way to extend.

    line 93

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Building Accessible Interfaces

Accessibility failures are concentrated in a few places: custom controls built from divs, inputs without labels, invisible focus, low-contrast "subtle" text, and modals that trap nothing or everything. Check those first; they cover most real users' problems and most automated findings.

Contents

  • Step 1 — Semantic HTML first
  • Step 2 — Every control has a name
  • Step 3 — Keyboard and focus
  • Step 4 — Contrast, measured
  • Step 5 — Motion, zoom and touch
  • Step 6 — Automated checks plus a manual pass
  • Native apps
  • Anti-patterns

Step 1 — Semantic HTML first

The right element gives keyboard support, focus and screen-reader semantics for free.

NeedUseNot
Action<button type="button"><div onclick>, <a href="#">
Navigation<a href="/path"><button onclick="location=…">
Page regions<header> <nav> <main> <footer>anonymous divs
Headingsone <h1>, then <h2>… in orderbold divs, skipped levels
Lists<ul>/<ol>stacked divs
Data<table> with <th scope>grids of divs
Toggle<input type="checkbox"> / <button aria-pressed>a styled span

ARIA is for the gaps HTML cannot fill (tabs, comboboxes, live regions). "No ARIA is better than bad ARIA": a wrong role actively misinforms assistive tech.

Step 2 — Every control has a name

  • Inputs: a visible <label for>; placeholder text is not a label (it disappears and is usually low contrast).
  • Icon-only buttons: aria-label="Delete contact" (the action and its object).
  • Images: meaningful alt; decorative images alt="".
  • Errors: tie the message to the field with aria-describedby and set aria-invalid="true"; see the designing-interaction-states skill for wording.
  • Links: text that makes sense alone — "View invoice #1042", not "click here".

Step 3 — Keyboard and focus

Unplug the mouse and use Tab, Shift+Tab, Enter, Space, Esc and the arrow keys.

  • Every interactive element is reachable, in visual order, with a visible focus indicator. Never outline: none without a replacement; use :focus-visible { outline: 2px solid <focus color>; outline-offset: 2px; }.
  • Modals: move focus into the dialog on open, keep Tab inside it, close on Esc, return focus to the trigger on close. The native <dialog> element with showModal() does most of this.
  • Menus and popovers close on Esc and on outside click; focus does not get lost.
  • Add a "Skip to content" link as the first focusable element on content-heavy pages.
  • No keyboard traps; no tabindex greater than 0.

Step 4 — Contrast, measured

WCAG AA: 4.5:1 for normal text, 3:1 for large text (≥ 24px, or ≥ 18.66px bold) and for UI component boundaries and focus indicators. Measure; do not judge by eye.

# axe reports contrast failures with the exact ratio and element
npx --yes @axe-core/cli "http://127.0.0.1:$PORT/" --tags wcag2a,wcag2aa

Common failures: grey placeholder text, muted helper text below ~#767676 on white, white text on light brand colors, disabled-looking "secondary" buttons. Check both light and dark themes. Never convey meaning by color alone — pair red with an icon or text ("Overdue").

Step 5 — Motion, zoom and touch

  • Respect prefers-reduced-motion: disable parallax, auto-playing animation and large transitions.

    @media (prefers-reduced-motion: reduce) {
      *, *::before, *::after { animation-duration: 0.01ms !important; transition-duration: 0.01ms !important; scroll-behavior: auto !important; }
    }
  • Text resizes to 200% without loss of content; use rem for type, never disable zoom (user-scalable=no).
  • Touch targets at least 44×44px (24×24px absolute minimum with spacing).
  • Do not auto-advance carousels or time out forms without a way to extend.

Step 6 — Automated checks plus a manual pass

Automated tools catch roughly a third of issues; they are a floor, not a verdict.

# tests/test_a11y.py — Playwright + axe; run with: uv run --with playwright --with axe-playwright-python pytest
from axe_playwright_python.sync_playwright import Axe

def test_home_has_no_serious_violations(page, live_server_url):
    page.goto(live_server_url + "/")
    results = Axe().run(page)
    serious = [v for v in results.response["violations"] if v["impact"] in ("serious", "critical")]
    assert not serious, results.generate_report()

Then, for every UI PR: a 2-minute keyboard pass of the changed screen, a contrast check of any new colors, and (for significant flows) a quick pass with VoiceOver (Cmd+F5 on macOS) to hear that controls announce sensible names.

Native apps

SwiftUI and UIKit give most of this through system components: use Button, Toggle, Label and standard lists; support Dynamic Type (text styles, not fixed point sizes); add .accessibilityLabel to icon-only buttons; group related elements with .accessibilityElement(children: .combine); test with VoiceOver and the Accessibility Inspector, and at the largest Dynamic Type size.

Anti-patterns

  • div and span click handlers instead of buttons and links.
  • Removing focus outlines for aesthetics.
  • Placeholder-as-label forms.
  • Light grey text to look "minimal".
  • Accessibility deferred to "a later audit" — retrofitting costs far more than using the right element now.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.