Web Accessibility · 2026 Edition

Build interfaces
everyone can use.

Interactive accessibility training for developers. Break inaccessible interfaces, experience the friction, fix the implementation, and learn how to test it.

Current WCAG 2.2 criteria
86
UI patterns
10
Playgrounds
4
Live tools
5

How 508 Dev teaches

Learn by repairing the interface.

Standards explain the requirement. The lab turns it into a practical engineering loop.

  1. 1Learn

    Understand the requirement and the people it affects.

  2. 2Experience

    Try the inaccessible version using the affected interaction.

  3. 3Fix

    Compare the repaired behavior and inspect the implementation.

  4. 4Test

    Run manual checks and record browser and assistive-technology results.

Interactive playgrounds

Feel the friction.

Reading WCAG won't make you fluent. Each playground below is a real, working comparison — toggle, tap, and try the broken version to understand why the criterion exists.

WCAG 2.2 · 2.5.8 Level AA

Target Size (Minimum)

WCAG 2.2 SC 2.5.8 establishes a 24 × 24 CSS pixel minimum at Level AA, with spacing, equivalent-control, inline, user-agent-control, and essential-presentation exceptions. Larger targets can still be easier to operate.

Fails when no exception applies

A 16 × 16 px button placed near other targets can fail both the size requirement and spacing exception.

Hits: 0
Passes AA and enhanced AAA size

A 44 × 44 CSS px target meets WCAG 2.5.5 Target Size (Enhanced), Level AAA, as well as the AA minimum.

Hits: 0

Keep the categories separate: WCAG 2.2 AA defines the 24 × 24 CSS px requirement and its exceptions; WCAG 2.5.5 defines the enhanced 44 × 44 CSS px AAA criterion; platform and design-system guidance may recommend other sizes. Read the W3C explanation (opens in a new tab).

WCAG 2.2 · 3.3.7 Level A

Redundant Entry

Information previously entered in the same process must be auto-populated or selectable — never re-typed. Helps users with cognitive disabilities and short-term memory loss.

Fails 3.3.7

Shipping address

Billing address (re-enter)

⚠️ User must re-type 3 fields they just entered.

Passes 3.3.7

Shipping address

Billing address

✓ One checkbox eliminates re-entry entirely.

WCAG 2.1 · 1.4.11 Level AA

Non-text Contrast

UI components and meaningful graphics need a contrast ratio of at least 3:1 against adjacent colors. Borders, icons, states — not just text.

Create your account

Quick sign-up to continue.

Border ratio
1.2:1
Button ratio
1.4:1
Icon ratio
1.3:1
WCAG 2.1 · 1.3.5 Level AA

Identify Input Purpose

Use HTML autocomplete tokens so browsers, password managers, and assistive tech understand each field's purpose.

Fails 1.3.5

No autocomplete. The browser can't help.

Not accessible signin.html
<input type="text"
       placeholder="first thing">

No autocomplete token. Browser autofill, password managers, and assistive tech have no idea what this field is for.

Passes 1.3.5

Semantic autocomplete tokens. Try focusing each field — your browser will offer saved data.

Accessible · WCAG 1.3.5 signin.html
<input type="text" name="name"
       autocomplete="name">

The highlighted autocomplete="name" token tells browsers, password managers, and screen readers exactly what this field collects.

Common autocomplete tokens reference
nameFull name
given-nameFirst
family-nameLast
emailEmail
telPhone
street-addressAddress
postal-codeZIP / postcode
cc-numberCard number
bdayBirthday
current-passwordExisting pw
new-passwordNew pw
one-time-codeSMS/2FA code

Pattern library

Components, done right.

Reference implementations with keyboard maps, accessible-name guidance, and code you can adapt and test in your own product. Copy, adapt, ship.

Modal Dialog

2.1.2 2.4.3 4.1.2
EscClose TabTrapped EnterActivate
<dialog aria-labelledby="d-h">
  <h2 id="d-h">Confirm action</h2>
  <button autofocus>Cancel</button>
  <button>Confirm</button>
</dialog>
// Native <dialog> gives focus trap + Esc free
dialog.showModal();
<dialog ref={dialogRef} aria-labelledby="d-h">
  <h2 id="d-h">Confirm action</h2>
  <button autoFocus onClick={close}>Cancel</button>
</dialog>
// dialogRef.current.showModal()
<dialog ref="dialog" aria-labelledby="d-h">
  <h2 id="d-h">Confirm action</h2>
  <button @click="close" autofocus>Cancel</button>
</dialog>
// this.$refs.dialog.showModal()

Tabs

2.1.1 4.1.2
Project status, recent updates, team members.
← →Switch tab Home/EndFirst/Last
<div role="tablist">
  <button role="tab" aria-selected="true"
          aria-controls="p1" id="t1">Overview</button>
</div>
<div role="tabpanel" id="p1" aria-labelledby="t1">...</div>
// Arrow keys cycle, only selected tab is in tab order
<div role="tablist">
  {tabs.map((tab, i) => (
    <button key={i} role="tab"
       aria-selected={active === i}
       tabIndex={active === i ? 0 : -1}>
       {tab.label}
    </button>
  ))}
</div>

Combobox (Autocomplete)

2.1.1 4.1.2 1.3.1
    ↑ ↓Navigate EnterSelect EscClose
    <input role="combobox"
           aria-autocomplete="list"
           aria-expanded="false"
           aria-controls="list"
           aria-activedescendant="opt-3">
    <ul id="list" role="listbox">
      <li id="opt-3" role="option"
          aria-selected="true">Brazil</li>
    </ul>

    Toast / Snackbar

    4.1.3 2.2.1
    Changes saved successfully
    aria-live="polite"Announced softly
    <div role="status"
         aria-live="polite"
         aria-atomic="true">
      Changes saved successfully
    </div>
    // "polite" waits for the user to finish
    // Use "assertive" only for errors

    Tooltip

    1.4.13 4.1.2
    This is dismissible & persistent
    aria-describedbyRead after name EscDismissible
    <button aria-describedby="tip">Help</button>
    <div id="tip" role="tooltip">
      Click to share this article
    </div>
    // WCAG 1.4.13: must be hoverable + persistent + dismissible

    Skip Link

    2.4.1

    This page has a real one. Try pressing Tab from the address bar.

    It's the first thing screen reader & keyboard users hit. It must be visible on focus.

    TabFrom page top reveals it
    <a href="#main" class="skip">
      Skip to main content
    </a>
    
    /* Off-screen until focused */
    .skip { position: absolute; top: -100px; }
    .skip:focus { top: 1rem; }

    Accordion / Disclosure

    2.1.1 4.1.2
    Space / EnterToggle aria-expandedRequired
    <button aria-expanded="false"
            aria-controls="panel">
      Shipping info
    </button>
    <div id="panel" role="region"
         hidden>
      Free shipping…
    </div>
    // Toggle: button[aria-expanded] + panel[hidden]
    // Native: <details><summary> is simpler if pure HTML

    Menu / Dropdown

    2.1.1 4.1.2
    ↓ / EnterOpen ↑ ↓Navigate EscClose
    <button aria-haspopup="menu"
            aria-expanded="false"
            aria-controls="m">Actions</button>
    <ul id="m" role="menu">
      <li role="menuitem" tabindex="-1">Duplicate</li>
    </ul>
    // Note: a dropdown of LINKS is just a <ul> of <a> — no role="menu" needed

    Form Validation

    3.3.1 3.3.3 4.1.3
    aria-invalidMark errors aria-describedbyLink error text role="status"Announce
    <label for="e">Email</label>
    <input id="e" type="email" required
           aria-invalid="true"
           aria-describedby="e-err">
    <p id="e-err">Please enter a valid email.</p>
    <div role="status" aria-live="polite">
      Form has 2 errors. <a href="#e">Fix email</a>
    </div>
    // Validate on blur, not on every keystroke

    Date input

    1.3.5 3.3.2 4.1.2

    MM/DD/YYYY

    type="date"Native picker autocompleteNo token applies to a travel date
    <label for="d">Departure date</label>
    <input id="d" type="date"
           aria-describedby="d-fmt">
    <p id="d-fmt">MM/DD/YYYY</p>
    // Native is almost always better than a custom calendar
    // "bday" means the user's birthday; it is incorrect for travel dates
    // Custom calendars: APG datepicker is the reference

    Evidence, not assumptions

    Browser and assistive-technology matrix.

    A maintainable record for tested, partially tested, untested, and known-issue combinations. Nothing is marked tested without documented verification.

    Current browser and assistive-technology testing status
    BrowserScreen readerPlatformStatusNotes

    Live tools

    Test as you design.

    Stop guessing. Pick colors, see contrast. Click any element, see its accessibility tree. No tab switching.

    Contrast checker

    Aa

    The quick brown fox jumps over the lazy dog.

    Ratio
    21:1
    Higher is better
    Compliance

    Accessibility Tree Inspector

    Inspect the accessibility semantics exposed by the browser and approximate what assistive technologies may receive. Actual output varies by browser, operating system, accessibility API, screen reader, and screen-reader version.

    Click any element to inspect it…

    Health check

    Paste any HTML — a component, a page, a snippet — and get a fast static analysis. Catches the obvious 80% (missing alt text, unlabeled inputs, contrast issues, heading order, missing landmarks). Not a substitute for a real audit, but it'll surface what an auditor would flag in the first 5 minutes.

    Headings outline

    Inspect this page's H1–H6 outline. Skipped levels, missing H1, and empty headings are flagged. Screen-reader navigation behavior varies by product and version.

    Landmarks viewer

    Toggle the overlay to inspect page landmarks — banner, navigation, main, complementary, contentinfo, search, region, and form. Assistive technologies may expose and navigate this structure differently.

    Daily reference

    The reference manual.

    The four accessibility references web developers reach for most: ARIA attributes and roles, keyboard interactions by widget, semantic HTML, and live regions.

    ARIA reference

    Every ARIA attribute and role you'll reach for, with what it does and when not to use it. The first rule of ARIA: don't use ARIA if HTML can do it.

    Keyboard interaction by widget

    The keys each widget needs to support, distilled from the WAI-ARIA Authoring Practices. If you're building a custom component, this is the contract.

    Semantic HTML

    The foundation. Get this right and you skip half the ARIA you'd otherwise need.

    Landmarks

    Landmarks are how screen reader users jump around a page. Use the HTML elements — they have implicit ARIA roles and need no extra markup.

    ElementImplicit roleUse for
    <header>banner *Top of the page: logo, primary nav, search. * Only when a direct child of <body> — otherwise just a section header.
    <nav>navigationMajor navigation blocks. Multiple allowed — label each: aria-label="Primary", "Footer", etc.
    <main>mainPrimary content. One per page. Skip links target this.
    <aside>complementarySidebar, callout, related content — tangential to main flow.
    <footer>contentinfo *Site-wide footer: copyright, legal, secondary nav. * Only as direct child of <body>.
    <section>region (only with name)A generic section. Becomes a landmark only when given an accessible name via aria-labelledby or aria-label.
    <search>searchSearch interface (HTML 2023). Replaces role="search" on <form>.
    <form>form (only with name)Becomes a landmark only when given an accessible name.

    Heading hierarchy

    • One <h1> per page describing the page's primary purpose.
    • No skipping levels. Don't go h1 → h3. Screen readers navigate the hierarchy and gaps confuse the structure.
    • Use heading levels for semantics, not size. If the visual design needs a small heading, use <h2 class="text-sm"> — not <h4>.
    • Don't use empty headings. If you need spacing, use CSS. Empty <h2></h2> is announced as "heading level 2, blank" — disorienting.
    • For SPA route changes that don't reload the page: move focus to the new <h1> (with tabindex="-1") so screen reader users know they've navigated.

    Button vs link vs div

    ElementWhenGets you
    <button>Triggers an action on the current page (open modal, submit form, toggle state).Keyboard activation, Space+Enter, focus, role="button", correct AT announcement.
    <a href>Navigates somewhere — different page, anchor, external URL.Enter activates (Space scrolls!), right-click context menu, "open in new tab".
    <div role="button">Almost never. Only if there's an extraordinary reason a real <button> won't work.Nothing automatic. You add tabindex="0", Space/Enter handlers, disabled state — all the things <button> gives free.

    Test: if "open in new tab" makes sense, it's a link. Otherwise it's a button.

    Modern interactive elements

    Element / attributeWhat it does
    <details> <summary>Native disclosure widget. Keyboard, ARIA, animation — all free. Use this before reaching for custom JS.
    <dialog>Native modal element. showModal() handles focus trap, Esc-to-close, inert background automatically. Use this before building a custom modal.
    popover attributeNative popover (2024). For tooltips, dropdowns, and non-modal overlays. Pairs with popovertarget on the trigger.
    inert attributeRemoves a subtree from the accessibility tree and keyboard focus. Use on backgrounds while a modal is open.
    <input list>Native combobox via <datalist>. Limited but adequate for simple cases.

    The four ways to hide

    MethodVisualScreen readerKeyboardUse for
    display: noneHiddenHiddenSkippedTabs (inactive panel), accordion (closed panel).
    visibility: hiddenHiddenHiddenSkippedSame as display:none, but reserves layout space.
    aria-hidden="true"VisibleHiddenFocusable still!Decorative icons next to text. Never on focusable elements.
    .sr-only (CSS)HiddenReadSkipped (usually)Labels for icon buttons, status text, skip links until focused.

    Live regions

    How to announce things without moving focus. Among the most-misused parts of ARIA.

    Decision matrix

    What you're announcingUse thisWhy
    Form saved, item added to cart, copied to clipboardrole="status" or aria-live="polite"Non-urgent. Waits for the SR to finish its current sentence.
    Form has errors, payment failed, session expiringrole="alert" or aria-live="assertive"Urgent. Interrupts whatever the SR is reading.
    Chat message arrived, log entry appendedrole="log"Sequential additions. SR knows order matters.
    Elapsed time, countdownrole="timer"SR can choose not to announce every tick.
    Modal confirming a destructive actionrole="alertdialog"Combines alert urgency with dialog focus semantics.

    The supporting attributes

    AttributeDefaultWhat it controls
    aria-atomicfalseWhen true: the SR reads the entire region on any change. When false: just the changed part. Default is fine for most cases.
    aria-relevantadditions textWhich change types trigger an announcement: additions, removals, text, all. Don't override unless you have a specific reason.
    aria-busyfalseSet true while updating a region to suppress announcements until done. Set back to false to flush.

    Gotchas that will bite you

    • Live regions don't announce on initial render. The element must already exist in the DOM before the content changes. Render the empty region first, then update it.
    • Same content twice in a row may not re-announce. Screen readers deduplicate. To force re-announcement, briefly clear the region then set it again (or use a counter/timestamp in the text).
    • Moving focus interrupts announcements. If you announce and focus a new element, the focus change wins. For toast-style messages: don't move focus.
    • Assertive is for emergencies. Don't use it for "added to cart." Real users mute pages that constantly interrupt.
    • Visually hidden live regions still work. Use .sr-only if the announcement should be SR-only and not on screen.
    • Test in multiple SRs. NVDA, JAWS, VoiceOver, TalkBack all handle live regions slightly differently. The behavior you tested in one isn't the behavior in another.

    Code review

    Pre-merge checklist.

    The questions to ask before approving any PR with UI changes. Keep this open during code review. Progress saves locally.

    Federal Law

    Section 508

    Federal ICT accessibility requirements that apply to covered technology developed, procured, maintained, or used by federal agencies.

    Who it covers
    Federal agencies and covered federal ICT. Contract requirements can flow to vendors that supply federal technology.
    The standard
    The Revised 508 Standards incorporate WCAG 2.0 Level A and AA success criteria and conformance requirements by reference for covered web and non-web electronic content.
    Enforcement
    Compliance is handled within the federal statutory, procurement, and agency context. Consult the applicable agency process for a specific matter.
    Procurement teeth
    Procurements commonly request an Accessibility Conformance Report (ACR); the exact solicitation controls what a vendor must provide.
    Civil Rights Regulation

    ADA Title II

    Applies to state and local government entities. The DOJ's web and mobile app rule directly incorporates WCAG 2.1 Level A and AA for covered content, subject to the rule's exceptions.

    Who it covers
    State and local governments, called public entities under Title II.
    Current compliance dates
    April 26, 2027 for entities serving 50,000 or more people; April 26, 2028 for smaller entities and special district governments.
    Technical standard
    WCAG 2.1 Level A and AA, with definitions, exceptions, and defenses provided by the Title II rule.
    Civil Rights Law

    ADA Title III

    Applies to covered private places of public accommodation. Its web application is not identical to the DOJ's Title II rule and can depend on jurisdiction and facts.

    Who it covers
    Covered private places of public accommodation, including categories such as retail, lodging, food service, healthcare, education, and entertainment.
    The standard
    There is no single nationwide web-specific WCAG conformance rule equivalent to the Title II rule. WCAG is widely used as a technical benchmark.
    Enforcement
    Enforcement paths and available remedies depend on federal law, jurisdiction, and potentially applicable state law. Seek qualified legal advice for a specific situation.
    Landmark case
    Robles v. Domino's Pizza (9th Cir., 2019; cert. denied 2019) — confirmed Title III applies to websites and apps with a nexus to a physical place of accommodation.

    Selected legal developments.

    These examples illustrate how digital accessibility questions have been handled in particular jurisdictions. They are context, not a substitute for legal advice.

    Robles v. Domino's Pizza, LLC

    9th Circuit Court of Appeals · 2019
    Outcome

    Cert. denied by Supreme Court — confirmed ADA Title III applies to websites and apps with a nexus to a physical place of accommodation.

    Blind plaintiff couldn't order pizza via Domino's website or mobile app with a screen reader.

    Missing alt text, unlabeled form fields, custom JS controls without ARIA — the basics.

    Robles v. Domino's Pizza, LLC, 913 F.3d 898 (9th Cir. 2019), cert. denied, 140 S. Ct. 122 (2019) Established that ADA Title III applies to digital experiences with a nexus to a physical place of accommodation. Justia · 9th Cir. opinion

    National Federation of the Blind v. Target Corp.

    N.D. Cal. · 2008 (settlement)
    $6,000,000 Settlement

    First major ruling that retail e-commerce sites are subject to the ADA. Target paid $6M + adopted WCAG-equivalent standards.

    Inaccessible image maps, no keyboard navigation, missing alt text on product photos.

    National Federation of the Blind v. Target Corp., 452 F. Supp. 2d 946 (N.D. Cal. 2006); settled 2008 First major federal ruling that the ADA reaches retail e-commerce websites tied to physical stores. Justia · N.D. Cal. opinion

    People of the State of New York v. Sephora USA, Inc.

    New York Attorney General · 2022 (Assurance of Discontinuance)
    $2,000,000 Penalty + remediation

    Sephora.com inaccessible to blind users; required to bring site to WCAG 2.1 AA and audit annually.

    Color-only error states, missing form labels, focus traps in product carousel.

    In re Sephora USA, Inc., Assurance of Discontinuance No. 22-077 (N.Y. Att'y Gen. 2022) State AGs can enforce digital accessibility under state consumer-protection statutes — federal lawsuit not required. N.Y. AG · Assurance (PDF)

    Andrews v. Blick Art Materials, LLC

    E.D.N.Y. · 2017
    Outcome

    Federal judge held the ADA applies to standalone commercial websites — no physical nexus required.

    Used in subsequent suits as precedent for "pure" e-commerce. Opened the door to thousands of filings.

    Andrews v. Blick Art Materials, LLC, 268 F. Supp. 3d 381 (E.D.N.Y. 2017) Held that the ADA covers standalone commercial websites independent of any physical place of accommodation. Justia · E.D.N.Y. opinion

    Gil v. Winn-Dixie Stores, Inc.

    11th Circuit Court of Appeals · 2021 (vacated as moot)
    Outcome

    Trial court initially ruled Winn-Dixie's website violated the ADA. The 11th Circuit later reversed, holding websites are not themselves "places of public accommodation."

    Created a federal circuit split with the 9th Circuit (Robles). The 11th Circuit panel was later vacated as moot, but the disagreement among circuits remains unresolved by the Supreme Court.

    Gil v. Winn-Dixie Stores, Inc., 257 F. Supp. 3d 1340 (S.D. Fla. 2017); rev'd, 993 F.3d 1266 (11th Cir. 2021); vacated as moot, 21 F.4th 775 (11th Cir. 2021) Created a federal circuit split on whether standalone websites qualify as ADA "places of public accommodation." Justia · 11th Cir. opinion

    Tennessee v. Lane

    U.S. Supreme Court · 2004
    Outcome

    5–4 ruling that Title II of the ADA validly abrogates state sovereign immunity where fundamental rights (here, courthouse access) are at stake.

    Foundational Supreme Court precedent confirming that the ADA can require states to make public services — increasingly including digital services — accessible.

    Tennessee v. Lane, 541 U.S. 509 (2004) Supreme Court precedent that the ADA validly applies to state services when fundamental rights are implicated. Justia · Supreme Court opinion

    Engineering takeaway: Accessibility defects can create legal, operational, customer-experience, and remediation risk. Build accessibility into design, implementation, and review rather than relying on uncertain cost estimates.

    At a glance

    Dimension Section 508 ADA Title II ADA Title III
    ScopeCovered federal ICTState and local governmentsCovered private places of public accommodation
    Technical standardWCAG 2.0 A and AA incorporated by referenceWCAG 2.1 A and AA under the web/mobile ruleNo equivalent nationwide web-specific WCAG rule; WCAG is a common benchmark
    Primary authorityRehabilitation Act and Revised 508 StandardsADA and 28 C.F.R. Part 35, Subpart HADA and Title III regulations; application varies by jurisdiction and facts

    Reviewed against.

    Authority metadata is maintained centrally so versions, dates, sources, and jurisdiction notes can be updated consistently.

    Quick reference

    What's new in WCAG 2.2.

    Published October 2023. Nine new success criteria, all focused on cognitive disabilities, motor accessibility, and authentication friction.

    2.4.11
    Focus Not Obscured (Minimum)
    Level AA · The focused element must not be entirely hidden by other content.
    Sticky headers and cookie banners are the usual culprits. When a user tabs to an element, at least part of the focused element must remain visible. The strict AAA version (2.4.12) requires fully visible.
    2.4.13
    Focus Appearance
    Level AAA · Focus indicators must be at least 2 px thick with a 3:1 contrast ratio.
    The default browser focus ring rarely passes. This dashboard uses a 4 px outline with high contrast — try tabbing through it to see.
    2.5.7
    Dragging Movements
    Level AA · Any drag operation must have a single-pointer alternative.
    Kanban boards, signature pads, range sliders — provide buttons or text input as alternatives.
    3.3.8
    Accessible Authentication (Minimum)
    Level AA · No cognitive function test without an alternative.
    Don't force users to memorize, transcribe, or solve puzzles. Allow paste, support password managers, and offer alternatives like passkeys, magic links, or biometrics.

    Mobile a11y

    Mobile is different.

    Touch targets, orientation, reflow, motion. The criteria desktop audits skip get audited harder on mobile.

    2.5.5 / 2.5.8

    Touch target size

    WCAG 2.2 AA uses a 24×24 CSS px minimum with defined exceptions. WCAG 2.5.5 sets 44×44 CSS px at AAA; platform guidance uses its own units and recommendations.

    1.3.4

    Orientation

    Don't lock to portrait or landscape. Some users mount their device permanently in one orientation.

    1.4.10

    Reflow

    Content reflows to 320px CSS px wide without two-axis scrolling. Test in 320×256.

    1.4.12

    Text spacing

    Layout must survive 200% line height, 50% paragraph space, 16% letter space — without clipping or overlap.

    2.5.4

    Motion actuation

    If shake-to-undo exists, also offer a button. Motion-only triggers exclude users with tremors or mounted devices.

    1.4.4

    Text scaling

    Respect iOS Dynamic Type and Android font scale. Use scalable units, not absolute px for body text.

    2.5.1

    Pointer gestures

    Anything done with a swipe/pinch must also work with a single tap (or button). Don't gate features behind gestures.

    Spacing

    Target spacing

    Adjacent touch targets need 8px+ gap to prevent mis-taps for users with motor impairments. WCAG 2.5.8 partly covers this via "spacing".

    86 current criteria + 1 historical criterion

    The complete WCAG index.

    This dataset contains the 86 success criteria currently in WCAG 2.2 plus SC 4.1.1 Parsing, retained and labeled for WCAG 2.0/2.1 historical and policy reference. Select a number to open the W3C source.

    Level
    Version
    Principle

    Test yourself

    Quick check.

    Six questions. Real scenarios. Instant feedback with the WCAG citation that proves the answer.

    Trust and governance

    Show the work behind the guidance.

    How 508 Dev researches examples, evaluates its own accessibility, documents changes, and accepts corrections.

    Accessibility statement

    508 Dev is committed to a keyboard-operable, semantic, reflow-friendly learning experience with visible focus and reduced-motion support.

    Known limitations: browser and assistive-technology coverage is not yet verified across the full matrix, and browser-based simulations do not reproduce actual assistive-technology output.

    Review current testing status

    Methodology

    Standards guidance starts with W3C/WAI. Federal requirements use official U.S. government sources. Examples use native HTML first and document ARIA only when it supplies necessary semantics or state.

    Review primary sources

    Corrections and feedback

    Report inaccurate guidance, an accessibility defect, a broken example, or a browser/assistive-technology inconsistency. Include the page area, expected behavior, actual behavior, and test environment.

    Report an issue on GitHub (opens in a new tab)

    Sources & Legal References

    Every legal claim, standard, and case study in this platform is grounded in primary sources. Standards URLs point to the W3C and U.S. government canonical documents so they stay current as the specifications and guidance evolve.

    Standards & specifications

    • WCAG 2.1 (W3C Recommendation) A W3C technical standard incorporated by some regulations and used as a benchmark in other accessibility contexts. w3.org/TR/WCAG21
    • WCAG 2.2 (W3C Recommendation) Adds 9 new success criteria covering touch targets, focus visibility, and authentication. w3.org/TR/WCAG22
    • WAI-ARIA Authoring Practices Guide Reference patterns and keyboard interactions for every interactive widget. w3.org/WAI/ARIA/apg
    • Section 508 ICT Refresh (2018) Adopted WCAG 2.0 Level AA by reference as the federal standard for U.S. agencies and contractors. access-board.gov/ict

    Government resources

    • ADA.gov Official U.S. Department of Justice ADA portal. ada.gov
    • DOJ Guidance on Web Accessibility & the ADA (2022) Department of Justice's official position that ADA Title II and III apply to web content. ada.gov/resources/web-guidance
    • Section508.gov Federal government's central resource for Section 508 compliance, testing, and procurement. section508.gov
    • DOJ Title II Web & Mobile Rule fact sheet Current DOJ summary of the WCAG 2.1 Level AA requirement, exceptions, and compliance dates amended in 2026. ada.gov · current Title II fact sheet

    Landmark cases

    • Tennessee v. Lane, 541 U.S. 509 (2004) Supreme Court — ADA Title II validly applies to state services when fundamental rights are implicated. Justia · Supreme Court
    • NFB v. Target Corp., 452 F. Supp. 2d 946 (N.D. Cal. 2006) First major federal ruling that retail e-commerce sites are subject to the ADA. Justia · N.D. Cal.
    • Andrews v. Blick Art Materials, LLC, 268 F. Supp. 3d 381 (E.D.N.Y. 2017) ADA covers standalone commercial websites independent of any physical location. Justia · E.D.N.Y.
    • Robles v. Domino's Pizza, LLC, 913 F.3d 898 (9th Cir. 2019) Title III applies to digital experiences with a nexus to a physical place of accommodation. Justia · 9th Cir.
    • Gil v. Winn-Dixie Stores, Inc., 993 F.3d 1266 (11th Cir. 2021), vacated as moot Created the federal circuit split with the 9th Circuit over whether standalone websites are ADA "places of public accommodation." Justia · 11th Cir.
    • In re Sephora USA, Inc., AOD No. 22-077 (N.Y. Att'y Gen. 2022) State attorneys general can enforce digital accessibility under state consumer-protection laws. N.Y. AG · AOD (PDF)

    Testing & evaluation