Interactive accessibility training for developers. Break inaccessible interfaces, experience the friction,
fix the implementation, and learn how to test it.
Standards explain the requirement. The lab turns it into a practical engineering loop.
1Learn
Understand the requirement and the people it affects.
2Experience
Try the inaccessible version using the affected interaction.
3Fix
Compare the repaired behavior and inspect the implementation.
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.8Level 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.7Level 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.
WCAG 2.1 · 1.4.11Level 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.5Level 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
<inputtype="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
<inputtype="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.
<divrole="tablist"><buttonrole="tab"aria-selected="true"aria-controls="p1"id="t1">Overview</button></div><divrole="tabpanel"id="p1"aria-labelledby="t1">...</div>// Arrow keys cycle, only selected tab is in tab order
<divrole="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.134.1.2
This is dismissible & persistent
aria-describedbyRead after nameEscDismissible
<buttonaria-describedby="tip">Help</button><divid="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
<ahref="#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.14.1.2
Free shipping on orders over $50. Delivery in 3–5 business days.
Space / EnterTogglearia-expandedRequired
<buttonaria-expanded="false"aria-controls="panel">
Shipping info
</button><divid="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.14.1.2
Duplicate
Archive
Delete
↓ / EnterOpen↑ ↓NavigateEscClose
<buttonaria-haspopup="menu"aria-expanded="false"aria-controls="m">Actions</button><ulid="m"role="menu"><lirole="menuitem"tabindex="-1">Duplicate</li></ul>// Note: a dropdown of LINKS is just a <ul> of <a> — no role="menu" needed
<labelfor="e">Email</label><inputid="e"type="email"requiredaria-invalid="true"aria-describedby="e-err"><pid="e-err">Please enter a valid email.</p><divrole="status"aria-live="polite">
Form has 2 errors. <ahref="#e">Fix email</a></div>// Validate on blur, not on every keystroke
Date input
1.3.53.3.24.1.2
MM/DD/YYYY
type="date"Native pickerautocompleteNo token applies to a travel date
<labelfor="d">Departure date</label><inputid="d"type="date"aria-describedby="d-fmt"><pid="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
Browser
Screen reader
Platform
Status
Notes
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.
Element
Implicit role
Use for
<header>
banner *
Top of the page: logo, primary nav, search. * Only when a direct child of <body> — otherwise just a section header.
<nav>
navigation
Major navigation blocks. Multiple allowed — label each: aria-label="Primary", "Footer", etc.
<main>
main
Primary content. One per page. Skip links target this.
<aside>
complementary
Sidebar, 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>
search
Search 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
Element
When
Gets 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 / attribute
What 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 attribute
Native popover (2024). For tooltips, dropdowns, and non-modal overlays. Pairs with popovertarget on the trigger.
inert attribute
Removes 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
Method
Visual
Screen reader
Keyboard
Use for
display: none
Hidden
Hidden
Skipped
Tabs (inactive panel), accordion (closed panel).
visibility: hidden
Hidden
Hidden
Skipped
Same as display:none, but reserves layout space.
aria-hidden="true"
Visible
Hidden
Focusable still!
Decorative icons next to text. Never on focusable elements.
.sr-only (CSS)
Hidden
Read
Skipped (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 announcing
Use this
Why
Form saved, item added to cart, copied to clipboard
role="status"oraria-live="polite"
Non-urgent. Waits for the SR to finish its current sentence.
Form has errors, payment failed, session expiring
role="alert"oraria-live="assertive"
Urgent. Interrupts whatever the SR is reading.
Chat message arrived, log entry appended
role="log"
Sequential additions. SR knows order matters.
Elapsed time, countdown
role="timer"
SR can choose not to announce every tick.
Modal confirming a destructive action
role="alertdialog"
Combines alert urgency with dialog focus semantics.
The supporting attributes
Attribute
Default
What it controls
aria-atomic
false
When true: the SR reads the entire region on any change. When false: just the changed part. Default is fine for most cases.
aria-relevant
additions text
Which change types trigger an announcement: additions, removals, text, all. Don't override unless you have a specific reason.
aria-busy
false
Set 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.
Standards and legal context
Know what each framework does.
WCAG provides technical accessibility criteria. Applicable laws and regulations may incorporate
specific WCAG versions or use WCAG as an accessibility benchmark. Section 508, ADA Title II, and
ADA Title III have different scopes and should not be treated as interchangeable.
Educational use: 508 Dev provides technical accessibility education, not legal advice.
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.
II
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.
The claim
Blind plaintiff couldn't order pizza via Domino's website or mobile app with a screen reader.
Root cause
Missing alt text, unlabeled form fields, custom JS controls without ARIA — the basics.
National Federation of the Blind v. Target Corp.
N.D. Cal. · 2008 (settlement)
$6,000,000Settlement
First major ruling that retail e-commerce sites are subject to the ADA. Target paid $6M + adopted WCAG-equivalent standards.
Root cause
Inaccessible image maps, no keyboard navigation, missing alt text on product photos.
People of the State of New York v. Sephora USA, Inc.
New York Attorney General · 2022 (Assurance of Discontinuance)
$2,000,000Penalty + remediation
Sephora.com inaccessible to blind users; required to bring site to WCAG 2.1 AA and audit annually.
Root cause
Color-only error states, missing form labels, focus traps in product carousel.
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.
Significance
Used in subsequent suits as precedent for "pure" e-commerce. Opened the door to thousands of filings.
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."
Why it matters
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.
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.
Why it matters
Foundational Supreme Court precedent confirming that the ADA can require states to make public services — increasingly including digital services — accessible.
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
Scope
Covered federal ICT
State and local governments
Covered private places of public accommodation
Technical standard
WCAG 2.0 A and AA incorporated by reference
WCAG 2.1 A and AA under the web/mobile rule
No equivalent nationwide web-specific WCAG rule; WCAG is a common benchmark
Primary authority
Rehabilitation Act and Revised 508 Standards
ADA and 28 C.F.R. Part 35, Subpart H
ADA 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
0 of 87 entries
No criteria match those filters.
Test yourself
Quick check.
Six questions. Real scenarios. Instant feedback with the WCAG citation that proves the answer.
Your score
0/6
Keep going!
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.
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.
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.
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
WCAG 2 Quick Reference (W3C)
Customizable filter view of all success criteria, techniques, and failures.
w3.org/WAI/WCAG22/quickref
WAI Easy Checks (W3C)
First-pass manual audit checklist any developer can run on any page.
w3.org/WAI/test-evaluate