⚠️ ADA Title II deadline:— Is your site compliant?Check free →
ADA Title II Compliance Deadline: April 24, 2026
State and local government websites must meet WCAG 2.1 Level AA by this date. Private businesses also face ongoing ADA Title III litigation risk. Use this checklist to identify and fix accessibility gaps now.
Website Accessibility Checklist 2026: WCAG 2.1 AA & ADA Compliance
A complete website accessibility checklist for achieving WCAG 2.1 Level AA compliance. Covers keyboard navigation, screen reader compatibility, color contrast, images, forms, videos, dynamic content, and ADA compliance requirements for 2026.
WCAG 2.1 Level AA is organized around four principles (POUR): Perceivable, Operable, Understandable, and Robust. All content must satisfy these four principles for all users, including those using assistive technologies.
Perceivable
Information and UI components must be presentable in ways users can perceive — including those who cannot see images or hear audio.
Operable
UI components and navigation must be operable — including by users who cannot use a mouse and rely on keyboard or switch access.
Understandable
Information and UI operation must be understandable — clear language, consistent navigation, and helpful error messages.
Robust
Content must be interpreted reliably by assistive technologies including screen readers, now and as technologies evolve.
Legal Compliance Summary
!ADA Title II (Government): State/local government entities must meet WCAG 2.1 AA by April 24, 2026 (large jurisdictions) or April 26, 2027 (small jurisdictions).
!ADA Title III (Private Business): Businesses serving the public face ongoing litigation risk. Over 4,000 web accessibility lawsuits are filed annually in the US.
!Section 508 (Federal): Federal agencies and contractors must meet the Revised Section 508 Standards (aligned with WCAG 2.1 AA).
!EU Web Accessibility Directive: Public sector websites in the EU must comply with EN 301 549 (based on WCAG 2.1 AA).
2. Keyboard Navigation
All website functionality must be operable using only a keyboard. Users with motor disabilities, those who cannot use a mouse, and power users rely on keyboard navigation. This is one of the most commonly violated WCAG requirements.
How to Test
Unplug your mouse and navigate your entire website using Tab, Shift+Tab, Enter, Space, and arrow keys. Every interactive element must be reachable and operable.
Keyboard Navigation Checklist
✓All interactive elements are keyboard focusable — Links, buttons, form inputs, dropdowns, modals, tabs, accordions, date pickers.
✓Visible focus indicator — Every focused element must have a clearly visible focus ring or highlight. Do NOT use outline: none in CSS without a replacement.
✓Logical tab order — Focus should move left-to-right, top-to-bottom following the visual layout. Use tabindex="0" for custom interactive elements, avoid positive tabindex values.
✓No keyboard traps — Users must be able to navigate into AND out of every component using the keyboard alone. Modal dialogs should trap focus internally but release it when closed.
✓Skip navigation link — A "Skip to main content" link should be the first focusable element on every page, allowing keyboard users to skip repetitive navigation.
✓Dropdown menus — Must be operable with keyboard alone. Arrow keys for navigation within the dropdown; Escape to close; Enter to select.
✓No keyboard-only barriers — Features like drag-and-drop must have keyboard-operable alternatives.
✓Sufficient timing — If any time limits exist, provide a way to extend, adjust, or turn off the time limit (WCAG 2.2.1).
3. Screen Reader Compatibility
Screen readers (NVDA, JAWS, VoiceOver, TalkBack) convert web content to speech or Braille output. Your website must be coded so screen readers can accurately convey all information and functionality.
Screen Reader Checklist
✓Language attribute — Set <html lang="en"> (or appropriate language code). Screen readers use this to select the correct voice/pronunciation engine.
✓Page title — Every page must have a unique, descriptive <title> tag. Screen readers announce the page title when a new page loads.
✓Heading hierarchy — Use <h1>–<h6> semantically to create a logical document outline. One H1 per page. Don't skip heading levels (e.g., H2 → H4).
✓Landmark regions — Use HTML5 landmarks: <header>, <nav>, <main>, <footer>, <aside>, <section>. Screen reader users navigate by landmarks.
✓Descriptive link text — Avoid "click here", "read more", "learn more" as link text. Each link must make sense out of context.
✓Button labels — All buttons must have accessible names. Icon-only buttons need aria-label: <button aria-label="Close dialog">✕</button>
✓Status messages — Success/error messages that appear without page reload must use aria-live regions or role="alert" to be announced.
✓Decorative content hidden — Decorative images use alt="" and aria-hidden="true". Pure decorative SVGs use aria-hidden="true".
4. Color Contrast & Visual Design
Poor color contrast is the #1 most common WCAG failure — affecting 83% of the top 1 million websites (WebAIM Million 2024). Many users have low vision, color blindness, or use screens in bright sunlight.
WCAG Contrast Requirements
4.5:1Normal text (under 18pt/24px regular, or 14pt/18.67px bold) — WCAG AA minimum
3:1Large text (18pt/24px+ regular, or 14pt/18.67px+ bold) — WCAG AA minimum
3:1UI components and graphical objects (borders of inputs, focus indicators, chart elements)
✓Text contrast ≥ 4.5:1 — Check all text on your website, including placeholder text in form inputs.
✓UI component contrast ≥ 3:1 — Input borders, button outlines, focus rings, and chart lines must meet this ratio.
✓Color is not the only indicator — Don't rely on color alone to convey information (e.g., "required fields are in red"). Add an asterisk (*) or text label.
✓Error states — Error messages must not rely on color alone. Use icons, text, or patterns in addition to red color.
✓Text on images — Text overlaid on photographs must maintain 4.5:1 contrast against the image background. Use overlays or text shadows.
✓Reflow at 400% zoom — Content must reflow into a single-column layout when zoomed to 400% (WCAG 1.4.10). No horizontal scrolling required on mobile-width content.
✓Text resize to 200% — Text must remain readable when the browser text size is increased to 200% (use relative units like em/rem, not px for font sizes).
5. Images & Alt Text
Alt text (alternative text) describes images for users who cannot see them — including blind users, those with slow connections, and search engines. Missing or poor alt text is the second most common WCAG failure.
Alt Text Best Practices
✓Every informative image has alt text — Describe what the image conveys, not just what it shows. "Man smiling" vs "Business owner John Smith reviewing financials".
✓Decorative images use empty alt="" — Purely decorative images (backgrounds, dividers) should have alt="" so screen readers skip them.
✓Functional images describe function — A logo linking to the homepage: alt="Company Name - Return to homepage". A search icon button: alt="Search".
✓Complex images have long descriptions — Charts, graphs, and infographics need either a detailed alt text or a linked text alternative that presents the same data in text form.
✓No redundant alt text — If image caption already describes the image, use alt="" to avoid repetition.
✓Background images — CSS background images used decoratively need no alt. If they convey information, use an HTML img element with alt text instead.
✓SVG icons — Informational SVGs need a <title> element, role="img", and aria-labelledby. Decorative SVGs need aria-hidden="true".
✓CMS user uploads — Configure your CMS to require alt text for all uploaded images. Many WCAG violations come from content editors skipping this field.
6. Forms & Error Handling
Forms are often the most complex accessibility challenge — especially for screen reader users and those with cognitive disabilities. Missing labels are the 4th most common WCAG failure.
Forms Accessibility Checklist
✓Every input has a visible label — Use <label for="inputId"> associated with <input id="inputId">. Do NOT rely solely on placeholder text as a label.
✓Required fields indicated — Mark required fields clearly (asterisk + legend explanation, or text "(required)"). Also set required attribute on the input.
✓Error identification — When validation fails, identify the field in error by name and describe the error in text: "Email address: Please enter a valid email format (example@domain.com)".
✓Error announcements for screen readers — Errors should be programmatically linked to their input (aria-describedby), and the overall form error summary announced via role="alert" or aria-live.
✓Input type hints — Use autocomplete attributes (autocomplete="name", "email", "tel") to help users with cognitive disabilities and password managers.
✓Correct input types — Use type="email", type="tel", type="number", type="date" to trigger appropriate mobile keyboards and browser validation.
✓Error prevention on important actions — For purchases, legal submissions, or irreversible actions: allow review and correction before submission, or provide a confirmation step (WCAG 3.3.4).
✓CAPTCHAs have alternatives — If using CAPTCHA, provide an accessible alternative (audio CAPTCHA + link to human support) for users who cannot solve visual challenges.
7. Links & Buttons
Links and buttons are the primary interactive elements on the web. Empty links (3rd most common WCAG failure) and empty buttons (5th most common) create severe accessibility barriers for screen reader users.
Links & Buttons Checklist
✓Descriptive link text — Every link must make sense out of context. "Download ADA Compliance Report (PDF, 2.3 MB)" is good. "Click here" or "Read more" alone are not.
✓No empty links — A linked logo or icon with no text needs an aria-label or title: <a href="/" aria-label="Homepage"><img alt=""...></a>
✓Button purpose clear — Every button must have an accessible name (visible text, aria-label, or aria-labelledby). Icon-only buttons must have aria-label.
✓Use correct elements — Use <a> for navigation (changes URL), <button> for actions (submits form, opens modal). Do not use <div> or <span> as fake buttons/links without ARIA roles.
✓New window/tab warnings — If a link opens in a new tab, indicate this in the link text or with a screen-reader-only message: "Opens in new tab" (aria-label or span.sr-only).
✓File format/size disclosure — Links to downloads should indicate format and size: "Annual Report 2025 (PDF, 1.2 MB)".
✓Touch target size — Buttons and links must be at least 44×44 CSS pixels (WCAG 2.5.5, WCAG 2.2 added 2.5.8 at 24×24 minimum). Important for mobile users with motor disabilities.
8. Video & Audio Content
Multimedia content must be accessible to users who are deaf, hard of hearing, blind, or deafblind. Video is increasingly common — and increasingly scrutinized in accessibility audits.
Video & Audio Checklist
✓Captions for all video — Pre-recorded video with audio must have synchronized captions (closed or open). Auto-generated captions (YouTube, Zoom) alone are insufficient — they must be reviewed and corrected.
✓Audio description for video — When video contains visual information not conveyed in the audio track (e.g., text shown on screen, visual demonstrations), provide an audio description or text alternative.
✓Transcript for audio — Audio-only content (podcasts, recordings) must have a text transcript.
✓No autoplay with sound — Video or audio that autoplays for more than 3 seconds must have a pause/stop control (or not autoplay at all).
✓Media player is keyboard accessible — Embedded video players must have keyboard-accessible controls (play, pause, volume, captions toggle, fullscreen).
✓No flashing content — Content must not flash more than 3 times per second (seizure risk — WCAG 2.3.1).
✓Live captions — Live video (webinars, live streams) must have real-time captions (CART captioning or live auto-caption reviewed in real time).
9. Tables & Data Structures
Data tables present structured information that screen reader users navigate cell by cell. Without proper markup, table relationships are lost and data becomes meaningless.
Tables Checklist
✓Use HTML table elements — Data tables must use <table>, <thead>, <tbody>, <th>, <td>. Do not use CSS Grid or flexbox to visually create table layouts for data.
✓Table headers — Use <th scope="col"> for column headers and <th scope="row"> for row headers. Screen readers use scope to announce which header applies to each cell.
✓Table caption — Add <caption> as the first child of <table> to give the table a title: <caption>Q4 2025 Revenue by Region</caption>
✓Complex tables use id/headers — Tables with merged cells or multi-level headers need id attributes on headers and headers="id1 id2" on data cells.
✓Responsive tables — On mobile, ensure tables remain usable. Techniques: horizontal scroll with overflow-x:auto, or responsive card layout with data-label attributes for context.
✓Layout tables — If using a table purely for visual layout (legacy sites), add role="presentation" to remove it from the accessibility tree.
10. Dynamic Content & ARIA
Single-page apps, infinite scroll, modals, tooltips, and live regions create unique accessibility challenges. ARIA (Accessible Rich Internet Applications) attributes bridge the gap between dynamic behavior and assistive technology.
Dynamic Content Checklist
✓No ARIA is better than bad ARIA — Incorrectly applied ARIA makes accessibility worse. First use native HTML elements (button, input, nav). Only add ARIA when no native HTML element meets the need.
✓Live regions for dynamic content — Content that updates without page reload (scores, notifications, search results) must use aria-live="polite" (non-urgent) or aria-live="assertive" (urgent alerts).
✓Modal dialog management — When a modal opens: move focus to the modal; trap Tab/Shift+Tab within the modal; close on Escape; return focus to the triggering element on close; use role="dialog" and aria-labelledby.
✓Page title updates in SPAs — Single-page apps must update document.title on route changes so screen reader users know they're on a new "page".
✓Loading states — When content is loading, indicate this to screen readers. Use aria-busy="true" on the container, or announce "Loading…" in a live region.
✓Tooltips and popovers — Must be keyboard-accessible (visible on focus, not just hover) and dismissible with Escape. Use role="tooltip" and aria-describedby to associate with triggering element.
✓Custom widgets follow ARIA patterns — Tabs, carousels, accordions, tree views, and other custom widgets must follow the ARIA Authoring Practices Guide (APG) keyboard interaction patterns.
11. Document Structure & Semantics
Semantic HTML provides meaning and structure that assistive technologies rely on. A well-structured document benefits everyone — including search engines.
Document Structure Checklist
✓Semantic HTML elements — Use appropriate HTML elements: <nav> for navigation, <main> for primary content, <article> for self-contained content, <aside> for supplementary content, <footer> for footer.
✓Single H1 per page — One H1 per page containing the primary topic. H2s for major sections, H3s for subsections — logical hierarchy only.
✓Lists for list content — Navigation menus, feature lists, and sequential steps should use <ul>/<ol>/<li>. Screen readers announce list length and position.
✓Consistent navigation — Navigation menus must appear in the same location and order across all pages (WCAG 3.2.3).
✓Consistent identification — UI components with the same function must have the same accessible name across pages (WCAG 3.2.4). "Search" button should always say "Search", not "Go" on some pages.
✓Reading order — The order of content in the HTML source must match the logical reading order. Screen readers read in DOM order, not visual order.
✓Multiple ways to find content — Provide a site search, sitemap, or clearly organized navigation. Users must have at least two ways to find any page (WCAG 2.4.5).
12. Testing Tools & Ongoing Monitoring
Accessibility is not a one-time audit — it requires ongoing monitoring. Every code change, CMS update, or new content can introduce accessibility regressions.
Important Limitation
Automated tools catch 30–40% of WCAG violations. The rest require keyboard testing, screen reader testing, and expert judgment. Use automation as your first filter, not your final answer.
Testing Tool Stack
✓Automated scanning — PageGuard accessibility checker (free, scans any URL), WAVE, axe DevTools browser extension, Lighthouse. Run after every major code change.
✓Keyboard testing — Manually navigate your 5 most critical user flows using keyboard only. Do this for every release.
✓Screen reader testing — NVDA + Firefox (free, Windows); VoiceOver + Safari (built-in, Mac); TalkBack (Android). Test your primary user flows monthly.
✓Color contrast checker — WebAIM's contrast checker (webaim.org/resources/contrastchecker). Also available in browser DevTools (Accessibility panel in Chrome).
✓Browser DevTools — Chrome and Firefox Accessibility panels show the accessibility tree, ARIA properties, and keyboard shortcuts for inspecting interactive elements.
✓Continuous monitoring — Set up automated accessibility monitoring to catch regressions between manual audits. PageGuard can monitor your site's accessibility score automatically.
✓User testing with disabled people — The most valuable accessibility testing. Work with disabled users through organizations like Fable or UserZoom to validate real-world usability.
✓Accessibility statement — Publish an accessibility statement disclosing your conformance level, known limitations, and contact for accessibility feedback.
ADA Deadline: April 24, 2026
Check Your Website's Accessibility Score
Scan your website for WCAG 2.1 violations, color contrast issues, missing alt text, and ADA compliance gaps — free in 30 seconds. No signup required.
Frequently Asked Questions
What is WCAG and what level should I target?
+
WCAG 2.1 Level AA is the standard you should target. It's required by the ADA Title II rule for government websites (deadline April 24, 2026), referenced in most accessibility lawsuits, and achievable with standard development practices. Level A is insufficient; Level AAA is often impractical for most web content.
What is the ADA Title II deadline for websites?
+
April 24, 2026 for state and local government entities with populations of 50,000+. April 26, 2027 for smaller jurisdictions. Private businesses (Title III) face ongoing litigation risk — over 4,000 web accessibility lawsuits are filed annually in the US.
What are the most common website accessibility errors?
+
According to WebAIM Million 2024: (1) Low color contrast — 83% of pages; (2) Missing alt text — 55%; (3) Empty links — 49%; (4) Missing form labels — 45%; (5) Empty buttons — 28%; (6) Missing document language — 17%. Fixing these six issues eliminates the vast majority of WCAG violations.
Do accessibility overlays make my site compliant?
+
No. Accessibility overlay products (UserWay, AccessiBe, etc.) cannot fix all WCAG violations, have been sued under the ADA, and have been condemned by hundreds of accessibility professionals. True compliance requires fixing actual code issues. Use overlays only as a temporary measure while remediating, never as a permanent solution.
How do I test website accessibility?
+
Use a multi-layer approach: (1) Automated tools (PageGuard, WAVE, axe) catch 30–40% of issues; (2) Keyboard testing — navigate the entire site with keyboard only; (3) Screen reader testing with NVDA/VoiceOver; (4) Color contrast checking; (5) User testing with disabled people for real-world validation. Automated scanning alone is insufficient for compliance.