askill
accessibility

accessibilitySafety 100Repository

Web accessibility checklist covering WCAG guidelines, ARIA patterns, keyboard navigation, color contrast, screen reader support, and form accessibility. Use when building UI components, reviewing frontend code, or when accessibility is mentioned.

1 stars
1.2k downloads
Updated 2/6/2026

Package Files

Loading files...
SKILL.md

Accessibility

Decision Tree

Building UI → What needs a11y attention?
    ├─ Interactive element (button, link, form) → Keyboard + screen reader + focus
    ├─ Image or icon → Alt text or aria-hidden
    ├─ Custom component (dropdown, modal, tabs) → ARIA roles + keyboard patterns
    ├─ Color or styling → Contrast + not color-only indicators
    ├─ Dynamic content (toast, live region) → aria-live announcements
    └─ Full page/app audit → Run checklist below

WCAG Quick Reference (Level AA)

PrincipleRequirementCheck
PerceivableText alternatives for imagesAll <img> have meaningful alt (or alt="" if decorative)
Color contrast4.5:1 for normal text, 3:1 for large text
Don't rely on color aloneUse icons, patterns, or text alongside color
Captions for videoProvide captions and transcripts
OperableKeyboard accessibleEvery interactive element reachable and operable via keyboard
Visible focus indicator:focus-visible styles on all interactive elements
No keyboard trapsUser can always Tab out of any component
Skip navigation"Skip to main content" link as first focusable element
UnderstandablePage language set<html lang="en">
Form labelsEvery input has a visible <label> with for attribute
Error identificationErrors described in text, not just red border
RobustValid HTMLProper heading hierarchy (h1→h2→h3, no skipping)
ARIA used correctlyOnly when native HTML can't do it

Keyboard Patterns

ComponentExpected Keyboard Behavior
ButtonEnter or Space activates
LinkEnter navigates
Modal/DialogEscape closes, focus trapped inside, returns focus on close
Dropdown/MenuArrow keys navigate, Enter selects, Escape closes
TabsArrow keys switch tabs, Tab moves to panel content
CheckboxSpace toggles
FormTab moves between fields, Enter submits

ARIA — Only When Needed

Rule #1: Don't use ARIA if native HTML works.
  <button> not <div role="button">
  <nav> not <div role="navigation">
  <input type="checkbox"> not <div role="checkbox">

When ARIA IS needed

PatternARIA
Custom dropdownrole="listbox", role="option", aria-expanded, aria-activedescendant
Modal dialogrole="dialog", aria-modal="true", aria-labelledby
Tabsrole="tablist", role="tab", role="tabpanel", aria-selected
Toast/notificationrole="alert" or aria-live="polite"
Loading statearia-busy="true", aria-live="polite" with status text
Icon buttonaria-label="Close" (no visible text)
Progressrole="progressbar", aria-valuenow, aria-valuemin, aria-valuemax

Form Accessibility

<!-- Always: visible label linked to input -->
<label for="email">Email address</label>
<input id="email" type="email" required aria-describedby="email-error">
<span id="email-error" role="alert">Please enter a valid email</span>

<!-- Never: placeholder as the only label -->
<input placeholder="Email"> <!-- Screen reader can't reliably read this -->

Checklist:

  • Every input has a <label> with for attribute
  • Required fields indicated (not just by color)
  • Error messages linked via aria-describedby
  • Error messages use role="alert" for screen reader announcement
  • Submit button has clear text (not just an icon)
  • Autocomplete attributes set (autocomplete="email", etc.)

Color Contrast

ElementMinimum Ratio (AA)Tools
Normal text (<18px)4.5:1WebAIM Contrast Checker
Large text (≥18px bold or ≥24px)3:1Chrome DevTools
UI components (borders, icons)3:1Figma a11y plugins

Don't rely on color alone:

BAD:  Red text for errors (colorblind users can't see it)
GOOD: Red text + error icon + descriptive message

Testing

# Automated (catches ~30% of issues)
npx axe-core-cli http://localhost:3000   # axe accessibility scanner
npx pa11y http://localhost:3000           # WCAG compliance checker

# Chrome DevTools
# Lighthouse → Accessibility audit
# Elements → Accessibility pane (inspect ARIA tree)

Manual testing (catches the rest):

  • Tab through the entire page — can you reach and operate everything?
  • Turn off CSS — does the content still make sense?
  • Use a screen reader (VoiceOver on Mac, NVDA on Windows)
  • Zoom to 200% — does the layout break?

Anti-Patterns

Anti-PatternFix
<div onclick> instead of <button>Use semantic HTML elements
Missing alt text on imagesAdd alt="description" or alt="" if decorative
Removing focus outlines (:focus { outline: none })Style :focus-visible instead of removing
tabindex="5" (positive tabindex)Use tabindex="0" or -1 only
aria-label on elements that have visible textRemove — screen readers read visible text
Color-only error indicationAdd text + icon alongside color
Auto-playing mediaNever autoplay, or provide immediate stop control
Missing skip navigationAdd "Skip to main content" as first link
Custom components without keyboard supportImplement full keyboard pattern
role="button" without Enter/Space handlingUse native <button> instead

Install

Download ZIP
Requires askill CLI v1.0+

AI Quality Score

98/100Analyzed 2/12/2026

An exceptionally comprehensive and actionable guide for web accessibility. It covers WCAG standards, ARIA usage, keyboard patterns, and testing tools with clear examples and checklists.

100
100
100
100
95

Metadata

Licenseunknown
Version-
Updated2/6/2026
PublisherBigPapiCB

Tags

api