Skip to main content
A11Y Checklist
MCP Server (opens in a new tab)
GitHub (opens in a new tab)

Content

0/3
Bad

It is a no-brainer that we will move the needle and circle back once we have boiled the ocean on this synergistic, paradigm-shifting deliverable.

Good

This is a simple choice. We will work on it together and update you next week.

Write at an 8th-grade reading level. Avoid jargon, idioms, and unnecessarily complex vocabulary.

Why it matters: Plain language reduces cognitive load, benefiting users with cognitive disabilities, non-native speakers, and readers who are stressed or multi-tasking.

Bad
Read moreClick hereLearn more
Good
Read the 2025 accessibility reportDownload the WCAG quick-reference PDFView pricing for the Pro plan

Button, <a>, and <label> content must be unique and descriptive enough to make sense out of context.

Why it matters: Descriptive link text provides context to keyboard and screen reader users, allowing them to browse a list of links without needing to read the surrounding text.

Bad

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.

Good

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi.

Use left-aligned text for LTR languages. Never use justified or centered body text.

Why it matters: Justified or centered body text is highly difficult to read for people with reading disabilities like dyslexia, as it creates uneven spacing and visual rivers of white space.

Global code

0/9
Bad

Hello world

  • orphan list item

    • ⚠ Malformed nesting

    Good

    Hello world

    • list item

    ✓ Valid HTML

    Write valid HTML. No unclosed tags, duplicate IDs, or malformed nesting.

    Why it matters: Valid HTML guarantees that assistive technologies can parse and navigate the page's DOM tree reliably and consistently across all standard browsers.

    Bad
    <html>
  <head>...</head>
</html>
    Good
    <html lang="en">
  <head>...</head>
</html>

    Always include a lang attribute on the <html> element, e.g., <html lang="en">.

    Why it matters: The lang attribute allows screen readers to choose the correct voice engine, phonetic profiles, and pronunciation rules to announce content accurately.

    Bad
    📄 Untitled
    📄 Untitled
    📄 Untitled
    Good
    📄 Pricing — Acme
    📄 Contact — Acme
    📄 Docs — Acme

    Every page/view must have a unique <title> element that describes its content.

    Why it matters: Page titles are the first things announced by screen readers when navigating. They allow users to quickly identify if they have reached their desired destination.

    Bad
    <meta name="viewport" content=
  "width=device-width,
  initial-scale=1,
  maximum-scale=1,
  user-scalable=no">
    Good
    <meta name="viewport" content=
  "width=device-width,
  initial-scale=1">

    Never use maximum-scale=1 or user-scalable=no in the viewport meta tag.

    Why it matters: Disabling viewport scaling locks out visually impaired users who depend on browser or mobile zoom to read small text and interact with layouts.

    Bad
    <div class="header">…</div>
    <div class="nav">…</div>
    <div class="main">…</div>
    Good
    <header>…</header>
    <nav>…</nav>
    <main>…</main>
    <footer>…</footer>

    Use <header>, <nav>, <main>, <footer>, and <aside> to structure page regions semantically.

    Why it matters: Landmark elements (header, nav, main, footer) allow screen reader users to skip directly to major layout regions, bypassing repetitive content.

    Bad

    Tab order: 3→1→4→2

    Good

    Natural DOM order: A→B→C→D

    Having an illogical tab order makes navigation confusing for those using assistive technology.

    Why it matters: Positive tabindex values create jumbled keyboard navigation order that confuses keyboard-only and screen reader users.

    Bad
    Good

    ✓ No autofocus — user controls where focus goes

    Never use the autofocus attribute on inputs.

    Why it matters: Autofocus disorients screen reader and low-vision users by moving focus without warning, bypassing important introductory content on page load.

    Bad

    Session expiring

    You will be logged out in 0:14

    Good

    Session expiring

    You will be logged out in 0:14

    Any session timeout must show a visible warning and offer a way to extend the session.

    Why it matters: People with motor, reading, or cognitive difficulties need more time to complete actions. Warn them before logging out so they do not lose progress.

    Bad

    ⚠ Info hidden in title — not accessible

    Good

    Never use the title attribute as the only label for interactive elements.

    Why it matters: The title attribute tooltip is inaccessible to keyboard-only and mobile touch users. Important label text must be visible or accessible via screen readers.

    Keyboard

    0/3
    Bad

    Tab to this button — no indicator appears

    Good

    Tab here — a clear blue ring appears

    Never set outline:none or outline:0 on interactive elements.

    Why it matters: Visible focus indicators are like a mouse cursor for keyboard users. Removing them makes it impossible to know which button or input has active focus.

    Bad

    DOM order: Right, Left, Right, Left

    Good

    DOM order matches reading order

    Tab order must match visual reading order.

    Why it matters: When visual layout and tabbing order do not align, keyboard users will tab to unexpected regions, causing severe confusion and disorientation.

    Bad

    Tab twice — focus vanishes to hidden element

    Good

    ✓ Tab moves directly between visible buttons

    Elements hidden off-screen (menus, drawers) must not receive keyboard focus.

    Why it matters: If interactive controls hidden off-screen (like hamburger menus) can still receive keyboard focus, users get trapped in a hidden, confusing tab loop.

    Images

    0/4
    Bad
    🐱
    <img src="cat.jpg">

    Screen reader: "cat.jpg"

    Good
    🐱
    <img src="cat.jpg" alt="A ginger tabby cat on a windowsill">

    ✓ Descriptive alt text

    Every <img> must have an alt attribute.

    Why it matters: Screen readers read alt text aloud to visually impaired users. Without alt text, the browser reads the file name, which is unhelpful and confusing.

    Bad

    Paragraph one.

    Paragraph two.

    SR announces: "decorative line divider image png"

    Good

    Paragraph one.

    Paragraph two.

    ✓ Screen reader skips the divider

    Decorative images must use alt="" and role="presentation" to be ignored by screen readers.

    Why it matters: Empty alt attributes (alt="") signal to screen readers that an image is decorative and should be skipped entirely, reducing verbal noise.

    Bad

    No description — SR: "chart"

    Good
    Monthly sales: Jan 40, Feb 70, Mar 50, Apr 90, May 60 units

    Charts, graphs, and maps must have a text alternative or accompanying data table.

    Why it matters: Complex visual data like charts, maps, and infographics cannot be summarized in a simple sentence. Providing a structured data table ensures full accessibility.

    Bad
    FedEx
    alt="company logo"

    SR: "company logo"

    Good
    FedEx
    alt="FedEx"

    SR: "FedEx" ✓

    Alt text for images containing text must include the image's text verbatim.

    Why it matters: Any text embedded within an image is completely invisible to screen readers, translation tools, and text-resizing tools unless reproduced in the alt description.

    Headings

    0/4
    Bad

    Pricing

    Plans for every team

    ⚠ Visual heading, semantic paragraph

    Good

    Pricing

    Plans for every team

    ✓ Semantic h2

    Use <h1>–<h6> for headings. Never use styled paragraphs or divs as visual headings.

    Why it matters: Proper heading elements organize content semantically, allowing screen reader users to navigate the document structure easily and skip directly to sections.

    Bad

    Page Title (h1)

    Section Title (h1)

    Article Title (h1)

    ⚠ Three h1 elements!

    Good

    Page Title (h1)

    Section Title (h2)

    Article Title (h3)

    ✓ Single h1, then h2, h3

    Only one <h1> per page.

    Why it matters: Using a single H1 acts as the clear title for the page, orienting screen reader users and defining the core theme of the page for SEO and accessibility.

    Bad
    ✗h1: Page
    ✗h4: Skipped to 4!
    ✗h2: Back to 2
    ✗h6: Jumped to 6!
    Good
    ✓h1: Page
    ✓h2: Section
    ✓h3: Subsection
    ✓h2: Next Section

    Heading levels must follow logical nesting order.

    Why it matters: Consistent, descending heading levels (H1, H2, H3) provide a clear outline that maps the logical relationships between page topics.

    Bad

    h2: Overview

    h4: Details — skipped h3!

    ⚠ h3 was skipped

    Good

    h2: Overview

    h3: Subsection

    h4: Details

    ✓ Sequential levels

    Never skip a heading level (e.g. h2 directly to h4).

    Why it matters: Skipping heading levels (like jumping from H2 directly to H4) implies missing sections, confusing screen reader users who navigate by heading outline.

    Lists

    0/1
    Bad
    • Apples
    • Pears
    • Plums

    ⚠ Plain text — no list semantics

    Good
    • Apples
    • Pears
    • Plums

    ✓ SR: "list, 3 items"

    Use <ul>, <ol>, or <dl> for all list content.

    Why it matters: Semantic lists inform assistive technology of grouped items and the total count of items, helping users mentally structure the content.

    Controls

    0/6
    Bad
    Pricing (span with onClick)

    ⚠ Not a real link

    Good
    Pricing (real anchor)

    ✓ Keyboard navigable, bookmarkable

    Use <a href="..."> for navigation. Never use div or span elements as links.

    Why it matters: Links are built for navigation. Standard anchor tags provide essential keyboard features like Enter activation, status bar hover, and history tracking.

    Bad

    See our pricing or read the docs.

    Good

    Visit our pricing page or read the docs.

    ✓ Color AND underline — visible in grayscale

    Links must be distinguishable from body text by more than color alone.

    Why it matters: People with low vision or colorblindness cannot distinguish links from standard text if color is the only cue. Underlines ensure they stand out visually.

    Bad
    Good

    All interactive controls must have a visible :focus style.

    Why it matters: A clear, prominent focus indicator is vital for keyboard navigation, allowing users to know exactly where they are on the page.

    Bad
    Submit (div)

    ⚠ No keyboard activation, no Enter/Space

    Good

    ✓ Keyboard activatable, proper role

    Use <button> for all clickable actions.

    Why it matters: Standard buttons provide built-in Space and Enter activation. Faking buttons with div elements locks out keyboard-only and screen reader users.

    Tables

    0/3
    Bad
    Name
    Role
    Team
    Alice
    Dev
    Alpha
    Good
    NameRoleTeam
    AliceDevAlpha

    Use <table> for tabular data. Never use CSS Grid or div layouts for structured data.

    Why it matters: Semantic tables expose columns, rows, and cells to screen readers, allowing users to navigate and understand complex data points systematically.

    Bad
    ProductPrice
    Widget$9.99
    Good
    ProductPrice
    Widget$9.99

    Table headers must use <th scope="col"> or <th scope="row">.

    Why it matters: The scope attribute explicitly connects header cells to their corresponding data rows or columns, ensuring correct reading order in grid structures.

    Bad

    Q3 2025 Sales

    RegionTotal
    North$120k

    ⚠ Title is outside the table

    Good
    Q3 2025 Sales by Region
    RegionTotal
    North$120k

    Every data table must have a <caption> element.

    Why it matters: A table caption acts as a visible heading for the table, giving assistive technology users instant context about the table data before reading it cell by cell.

    Forms

    0/6
    Bad

    ⚠ No label — SR: "edit text"

    Good

    ✓ SR: "Email address, edit text"

    Every input must have an associated <label> element.

    Why it matters: Labels provide persistent descriptions. They stay visible when typing and are read automatically by screen readers when focusing on an input field.

    Bad

    Shipping speed

    ⚠ Group label not programmatically associated

    Good
    Shipping speed

    Group related inputs (radio, checkbox) in a <fieldset> with a <legend>.

    Why it matters: Fieldset and legend elements group related options, such as radio groups or address forms, providing essential shared context for screen reader users.

    Bad

    ⚠ No autocomplete attributes

    Good

    ✓ Browser can auto-fill correctly

    Personal data inputs must have autocomplete attributes set to appropriate values.

    Why it matters: The autocomplete attribute speeds up entry and reduces typing requirements, helping users with motor and cognitive difficulties fill forms easily.

    Bad

    Email is required

    No summary — user must find errors by tabbing

    Good

    ✓ Focus jumps here on submit fail

    On form submit failure, show an error summary list above the form.

    Why it matters: An error summary lists all form issues in one place, focused on submit failure. This allows users to review and navigate to fields needing correction.

    Bad

    Email is required

    ⚠ Error not linked to input

    Good

    Email is required

    ✓ SR announces error when field is focused

    Associate error messages with inputs using aria-describedby.

    Why it matters: Associating error text with fields using aria-describedby ensures screen readers automatically announce the specific error message when focusing a field.

    Bad

    Color alone — fails for colorblind users

    Good
    Error
    Valid

    Error, warning, and success states must use icons or text labels in addition to color.

    Why it matters: Color blind or visually impaired users cannot identify validation states (like red borders) unless supported by clear text labels or descriptive icons.

    Media

    0/3
    Bad
    Good
    <audio controls preload="none">
  <source src="clip.mp3">
</audio>

    ✓ User controls when audio plays

    Never autoplay audio or video. Always use controls and let users initiate playback.

    Why it matters: Autoplay audio can drown out screen reader speech, making it extremely difficult for visually impaired users to find controls to turn it off.

    Bad
    div controls
    Good

    Media controls must use semantic HTML: <button> for actions, <input type="range"> for sliders.

    Why it matters: Using standard, keyboard-accessible buttons for custom media players guarantees that all play, pause, and volume controls are fully functional for all users.

    Bad
    🎬 Video (autoPlay loop — no controls)

    ⚠ No way to pause

    Good
    🎬 ▶ Playing…

    All moving or auto-updating content must be pausable by the user.

    Why it matters: Any moving, blinking, or scrolling content must be pausable to avoid triggering seizure issues, distracting users, or blocking assistive technologies.

    Video

    0/2
    Bad
    🎬 Video
    <video controls><source src="talk.mp4"></video>

    ⚠ No <track> element

    Good
    🎬 [CC] Video with captions
    <track kind="captions" srclang="en" src="talk.vtt" default>

    ✓ Caption track present

    All prerecorded video must have captions via a <track kind="captions"> element.

    Why it matters: Captions are essential for deaf or hard-of-hearing users to access verbal dialogue and ambient sounds, while also helping non-native language learners.

    Bad
    Good
    ✓ Slow pulse (1 Hz — well below threshold)

    Also respects prefers-reduced-motion

    Never produce content that flashes more than 3 times per second.

    Why it matters: Strobe effects and fast flashing lights can trigger epileptic seizures. High-frequency animations must be avoided or strictly gated.

    Audio

    0/1
    Bad
    Podcast Episode 42

    ⚠ No transcript available

    Good
    Podcast Episode 42
    Transcript
    [Host]: Welcome to episode 42. Today we discuss web accessibility standards and their real-world impact on users with disabilities…

    All audio content must have a text transcript available on the same page.

    Why it matters: Transcripts provide access to audio content for deaf-blind users, users who prefer reading, and those in noisy environments where audio is impractical.

    Appearance

    0/6
    Bad

    ⚠ Gradient disappears in high contrast mode

    Good

    ✓ Visible in all contrast modes

    Interactive elements must remain usable in high contrast mode and forced-colors environments.

    Why it matters: Using system-color support ensures controls remain fully visible and usable in specialized layouts, such as Windows High Contrast Mode.

    Bad
    Card content here
    Good
    Card content here

    Layout must not break or clip content when text is scaled to 200%.

    Why it matters: Visually impaired users often scale browser text to 200%. Layouts must reflow cleanly without cutting off, overlapping, or hiding enlarged text content.

    Bad
    Good

    Labels must be visually close to the inputs they describe.

    Why it matters: Placing labels or related descriptions far away from inputs disorients screen magnifier users, who can only view a small portion of the screen at once.

    Bad
    report.pdf — (color only: red)
    data.csv — (color only: green)
    styles.css — (color only: red)
    Good
    report.pdfError
    data.csvPassing
    styles.cssError

    Never use color alone to convey state or meaning.

    Why it matters: Relying on color alone to convey details (like active pages or statuses) locks out users with color blindness, low vision, or monochrome monitors.

    Bad

    Click the green button on the right to continue.

    ⚠ "Green" and "right" are visual-only cues

    Good

    Click the green "Continue" button to proceed to the next step.

    ✓ Names the element — no visual cues needed

    Instructions must name the element they refer to, not just its position or appearance.

    Why it matters: Instructions must not rely on single sensory indicators (like 'click the red circle' or 'the button on the right') which are useless to blind users.

    Bad
    Nav 1
    Nav 2
    Sidebar
    Content (overlaps)
    Ads
    Footer 1
    Footer 2
    Footer 3
    Good
    Nav
    Main content
    Footer

    Layout must reflow to a single column at 320px without horizontal scrolling.

    Why it matters: Clean, logical, single-column reflow patterns ensure readability and ease of interaction across various screen widths and device magnifiers.

    Animation

    0/3
    Bad

    Fast + large motion

    Good

    Subtle, slow fade

    Animations must not flash more than 3 times per second.

    Why it matters: Loud, flashing, or fast-scaling animations can trigger visual vertigo, nausea, and severe distraction in users with vestibular disorders.

    Bad

    Hero Section

    No pause control

    Good

    Hero Section

    Background video must have a pause control.

    Why it matters: Moving backgrounds draw strong cognitive attention. Users with ADHD or vestibular disorders must be able to pause background videos to read text.

    Bad

    Spins forever — no motion guard

    Good

    Still when reduce-motion is on ✓

    All CSS animations must respect @media (prefers-reduced-motion: reduce).

    Why it matters: The prefers-reduced-motion query allows users with vestibular motion sensitivity to disable transitions, parallax effects, and spinning animations.

    Color contrast

    0/6
    Bad

    This text has ~2.5:1 contrast (fails 4.5:1 minimum)

    Good

    This text has ~19:1 contrast (well above 4.5:1)

    Normal text (<18px or <14px bold) must have at least 4.5:1 contrast ratio.

    Why it matters: Sufficient color contrast (minimum 4.5:1) ensures standard body text is legible for users with moderate low vision, color blindness, or in high-glare setups.

    Bad

    Heading (fails 3:1)

    Good

    Heading (passes 3:1 ✓)

    Large text (≥18px or ≥14px bold) must have at least 3:1 contrast ratio.

    Why it matters: Large text needs a minimum of 3:1 contrast ratio. This standard ensures high legibility while offering creative flexibility for page headers and callouts.

    Bad
    Search (~1.5:1 — fails)
    Good
    Search (~8:1 — passes ✓)

    UI icons must have ≥3:1 contrast against their background.

    Why it matters: UI controls, status indicators, and descriptive icons must maintain high contrast (3:1) so their functions are clearly recognizable.

    Bad

    Fails 3:1

    Good

    Passes 3:1 ✓

    Input borders must have ≥3:1 contrast against the adjacent background.

    Why it matters: High-contrast input borders (3:1) allow low-vision and cognitively impaired users to easily locate, outline, and focus form fields.

    Bad

    Overlaid Text (no scrim)

    Good

    Overlaid Text (dark scrim ✓)

    Text overlaid on images must meet the same contrast requirements as regular text.

    Why it matters: Busy photographic backgrounds make overlaid text illegible. Using dark scrims or solid backing plates ensures text meets safety contrast margins.

    Bad

    Select this text — selection is invisible!

    Good

    Select this text — clear blue highlight ✓

    Custom ::selection styles must maintain ≥4.5:1 contrast ratio.

    Why it matters: Custom text selection states must retain high contrast, ensuring selected text remains fully readable against the custom highlight color.

    Mobile and touch

    0/4
    Bad

    📱 Please rotate to landscape

    Page locked — portrait not supported

    Good

    ✓ Content adapts to any orientation

    Works in both portrait and landscape

    Never lock orientation. Content must work in both portrait and landscape modes.

    Why it matters: Locking the screen orientation to portrait or landscape prevents users on fixed mounts (like wheelchairs) from reading or interacting with the site.

    Bad
    This content is 400px wide → forces horizontal scroll on small screens
    Good
    Content wraps within the container — no horizontal scroll ✓

    No horizontal scrolling at 320px viewport width.

    Why it matters: Avoiding horizontal scroll at standard widths ensures content wraps vertically, allowing users of screen magnifiers and mobile devices to read smoothly.

    Bad
    18×18px
    Good
    44×44px ✓

    Touch targets must be ≥44×44px with adequate spacing between them.

    Why it matters: A minimum touch target size of 44x44px ensures people with tremors, motor impairments, or large fingers can activate controls without error.

    Bad

    ⚠ No gap — can't scroll without triggering

    Good

    ✓ Gaps = scroll dead zones

    Interactive elements must have enough spacing to prevent accidental activation.

    Why it matters: Adequate spacing around touch zones prevents accidental triggers and provides motor-impaired users a safe area to swipe and scroll.