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
- osmontero/opencode-skillstheir own version, first seen Oct 27, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- osmontero/opencode-skills★ 15same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository41 other files it gives its agents.
- wiring-application-configSkill
- shipping-build-artifactsSkill
- permissioning-ci-workflowsSkill
- concurrent-branchesSkill
- shipping-across-surfacesSkill
- writing-defect-reportsSkill
- reporting-derived-metricsSkill
- guarding-destructive-operationsSkill
- running-github-actions-efficientlySkill
- keeping-git-repos-cleanSkill
- designing-interaction-statesSkill
- designing-marketing-pagesSkill
- rendering-untrusted-contentSkill
- reproducing-ci-locallySkill
- running-resumable-sync-jobsSkill
- normalizing-text-for-measurementSkill
- calibrating-thresholds-and-baselinesSkill
- designing-interfacesSkill
- verifying-external-behaviorSkill
- building-go-projectsSkill
- building-browser-extensionsSkill
- designing-python-apisSkill
- building-python-clisSkill
- improving-python-code-qualitySkill
- building-python-communitiesSkill
- documenting-python-librariesSkill
- deferring-heavy-dependenciesSkill
- reviewing-python-librariesSkill
- building-llm-backed-featuresSkill
- building-python-mcp-serversSkill
- packaging-python-librariesSkill
- optimizing-python-performanceSkill
- setting-up-python-librariesSkill
- managing-python-releasesSkill
- auditing-python-securitySkill
- testing-python-librariesSkill
- building-python-web-appsSkill
- building-rust-cratesSkill
- building-scala-projectsSkill
- building-swift-appsSkill
- shipping-swift-appsSkill
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
- Very specific: line 54
Every interactive element is reachable, in visual order, with a visible focus indicator.
- Distinctive: line 61
Add a "Skip to content" link as the first focusable element on content-heavy pages.
- Very specific: line 62
No keyboard traps; no tabindex greater than 0.
- Distinctive: line 93
Do not auto-advance carousels or time out forms without a way to extend.
≈ “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.
Files
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.
| Need | Use | Not |
| Action | <button type="button"> | <div onclick>, <a href="#"> |
| Navigation | <a href="/path"> | <button onclick="location=…"> |
| Page regions | <header> <nav> <main> <footer> | anonymous divs |
| Headings | one <h1>, then <h2>… in order | bold 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 imagesalt="". - Errors: tie the message to the field with
aria-describedbyand setaria-invalid="true"; see thedesigning-interaction-statesskill 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: nonewithout 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 withshowModal()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
tabindexgreater 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,wcag2aaCommon 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
remfor 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
divandspanclick 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.
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
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.

