ADA Website Compliance Checklist: A Practical 2026 Guide

An ADA website compliance checklist helps you identify and remove barriers that prevent people with disabilities from using your website. A practical review should cover content, keyboard access, forms, navigation, multimedia, responsive behaviour and assistive technology compatibility. Automated scans are useful, but they must be combined with manual and user-based testing.

---

TL;DR

• Use WCAG 2.2 Level AA as a practical accessibility benchmark unless another standard is contractually or legally required.
• Test complete user journeys, not only individual pages.
• Ensure every function works with a keyboard.
• Provide meaningful text alternatives, captions and accessible documents.
• Check colour contrast, zoom, reflow and visible focus.
• Give form fields programmatic labels and useful error messages.
• Combine automated scans with manual and assistive technology testing.
• Publish an accessibility statement and provide an accessible feedback channel.
• Retest after design, content, platform or third-party component changes.

---

What Does ADA Website Compliance Mean?

The Americans with Disabilities Act prohibits disability-based discrimination in covered contexts. The U.S. Department of Justice states that the ADA applies to services, programs and activities offered online by state and local governments and to goods, services and activities offered online by businesses open to the public.

However, “ADA compliant” is not simply a badge generated by a website scanner. Accessibility must be evaluated by checking whether people with disabilities can perceive the content, navigate the interface, understand instructions and complete essential tasks.

The Department of Justice explains common website barriers in its official web accessibility guidance, including poor contrast, missing image alternatives, inaccessible forms, absent video captions and mouse-only navigation.

Legal obligations may vary by organisation, jurisdiction and service. The technical checklist below supports accessibility work but does not replace a legal review.

---

Which Accessibility Standard Should You Follow?

The Web Content Accessibility Guidelines provide testable technical criteria for digital accessibility. W3C organises WCAG under four principles:

• Perceivable: Users must be able to perceive the information.
• Operable: Users must be able to navigate and operate the interface.
• Understandable: Content and interactions must be clear and predictable.
• Robust: Content must work with browsers and assistive technologies.

W3C encourages organisations to use the latest WCAG version. WCAG 2.2 adds criteria addressing concerns such as focus visibility, dragging, target size, consistent help, redundant entry and accessible authentication. Review the official WCAG 2 overview and WCAG 2.2 standard when defining requirements.

For private businesses, the Department of Justice does not currently provide a detailed web regulation equivalent to the technical rule established for state and local governments. WCAG remains a widely used technical benchmark, but WCAG conformance and ADA compliance should not be treated as identical legal claims.

---

ADA Website Compliance Checklist

Use this checklist across representative pages, templates, components and complete user journeys.

1. Do Images and Visual Content Have Text Alternatives?

• Give informative images concise alt text that communicates their purpose.
• Use empty alt attributes for decorative images so screen readers can ignore them.
• Describe charts, diagrams and infographics in nearby text when a short alt description is insufficient.
• Give functional images, such as icon buttons, an accessible name describing the action.
• Do not repeat nearby captions unnecessarily in the alt text.
• Do not add descriptions to every decorative visual simply to satisfy a scanner.

Example

<img

  src="checkout-progress.png"

  alt="Checkout progress: delivery completed, payment is the current step"
/>

The right description depends on context. The same image may require different alt text when used for decoration, instruction or navigation.

2. Can Every Function Be Used With a Keyboard?

Test the website without touching a mouse.

• Reach links, buttons, menus, fields, dialogs and controls using the keyboard.
• Activate controls using standard keys such as Enter and Space.
• Keep focus order consistent with the visual and reading order.
• Make keyboard focus clearly visible.
• Prevent focus from becoming trapped inside widgets or menus.
• Move focus appropriately when dialogs open and return it when they close.
• Provide a “Skip to main content” link.
• Avoid custom clickable elements when a native button or link is available.
• Provide an alternative to interactions that require dragging.

A mouse-only date picker, navigation menu or upload control can prevent users from completing an otherwise accessible process.

3. Are Headings, Landmarks and Page Structure Meaningful?

• Give every page a descriptive and unique title.
• Use one clear H1 for the page topic.
• Organise subsections with logical H2 and H3 headings.
• Use semantic elements such as header, nav, main, aside and footer.
• Use lists, tables and quotations according to their meaning.
• Add table headers and associate them with the correct data cells.
• Set the page language in the HTML.
• Keep the DOM reading order aligned with the intended visual order.

Semantic HTML should be the first choice. Add ARIA only when native HTML cannot express the required name, role, state or relationship.

4. Is Text Readable and Visually Distinguishable?

• Maintain at least a 4.5:1 contrast ratio for normal text.
• Maintain at least a 3:1 ratio for large text.
• Check important icons, controls, boundaries and focus indicators for sufficient non-text contrast.
• Do not communicate status using colour alone.
• Allow text to resize to 200 percent without losing content or functionality.
• Check reflow at a viewport width equivalent to 320 CSS pixels.
• Ensure adjusted line, paragraph, letter and word spacing does not break the layout.
• Avoid images of text when real text can be used.
• Allow users to pause or stop moving content when required.

Test normal, hover, focus, active, disabled, validation and selected states. A colour combination that passes in the default state may fail when a button receives focus or an error appears.

5. Are Links, Buttons and Touch Targets Usable?

• Write link text that explains its destination or purpose in context.
• Avoid repeated vague labels such as “click here” or “learn more.”
• Ensure accessible names match or include the visible labels.
• Provide adequate spacing around small interactive targets.
• Do not hide focused controls behind sticky headers, cookie notices or chat widgets.
• Make controls visually identifiable without depending only on colour.
• Confirm that icon-only buttons have accessible names.
• Avoid nesting buttons inside links or links inside buttons.

Review reusable components before reviewing every page. Fixing a button, navigation or modal in the design system can resolve the same issue across many screens.

6. Are Forms and Error Messages Accessible?

• Connect every input with a visible programmatic label.
• Provide instructions before users encounter a complex field.
• Identify required fields using text or programmatic attributes, not colour alone.
• Group related options with fieldset and legend where appropriate.
• Explain validation errors clearly and identify the affected field.
• Move focus to an error summary or announce errors to assistive technology.
• Preserve entered information when validation fails.
• Use relevant autocomplete attributes for common personal information.
• Allow users to review and correct legal, financial or important data submissions.
• Avoid authentication tasks that depend entirely on memory, puzzles or inaccessible CAPTCHA.

Placeholder text is not a sufficient replacement for a label because it can disappear after typing and may have poor contrast.

7. Is Multimedia Accessible?

• Add accurate, synchronised captions to prerecorded videos with meaningful audio.
• Provide transcripts for audio-only content.
• Add audio descriptions when important visual information is not conveyed in the soundtrack.
• Give media players keyboard-accessible controls with clear names.
• Avoid automatically playing audio.
• Provide pause, stop or hide controls for moving content where required.
• Prevent content from flashing more than accessibility thresholds allow.
• Verify captions manually instead of publishing uncorrected automatic captions.

8. Does Dynamic Content Work With Assistive Technology?

• Give custom components accurate accessible names, roles, values and states.
• Announce meaningful status changes without unexpectedly moving focus.
• Manage focus when opening modals, displaying errors or completing steps.
• Ensure expandable controls expose their expanded or collapsed state.
• Test dropdowns, tabs, accordions, carousels and autocomplete fields independently.
• Avoid adding ARIA attributes that conflict with native HTML behaviour.
• Confirm that loading indicators, search results and cart updates are announced appropriately.

9. Do Mobile, Responsive and Zoomed Layouts Remain Usable?

• Test portrait and landscape orientation unless one orientation is essential.
• Check the site at 200 percent and 400 percent browser zoom.
• Prevent text, buttons and fields from overlapping or becoming clipped.
• Avoid horizontal scrolling for ordinary page content at narrow widths.
• Ensure menus remain operable with touch, keyboard and screen readers.
• Provide alternatives to device-motion interactions.
• Check touch targets and spacing on real mobile devices.
• Verify that browser text-size settings do not break critical journeys.

10. Are PDFs, Downloads and Third-Party Features Accessible?

• Use tagged headings, lists, tables and reading order in PDFs.
• Give form fields in downloadable documents accessible names.
• Provide an accessible HTML alternative when a document cannot be remediated promptly.
• Review embedded maps, payment forms, chat widgets, booking tools and cookie banners.
• Include accessibility requirements when selecting vendors.
• Document third-party limitations and establish an escalation process.
• Retest integrations after vendor updates.

A page cannot provide an accessible journey if its payment, appointment or document step remains inaccessible.

---

CTA: Download Your Free ADA Compliance Checklist

Make your website more accessible with a practical, step-by-step checklist covering keyboard navigation, forms, colour contrast, multimedia, mobile usability, and more.

CTA Button: Download Free Checklist

---

How Should You Test Your Website?

A credible website accessibility audit combines several methods.

Step 1: Define the Audit Scope

Create an inventory of:

• Main templates and shared components
• High-traffic pages
• Login and account areas
• Search and navigation
• Forms and error states
• Checkout, booking or application flows
• Multimedia and downloadable documents
• Third-party integrations

Include complete processes. Testing only a homepage can miss barriers that appear during payment, authentication or submission.

Step 2: Run Automated Checks

Automated tools can quickly identify certain code-level issues, including missing labels, duplicate IDs, empty links and some contrast failures. Options include axe DevTools, WAVE and Lighthouse.

Creole Studios’ guide to accessibility testing tools can help you compare testing options.

Do not interpret a zero-error scan as proof of compliance. Automated tools cannot reliably judge whether alt text is meaningful, focus order is logical or instructions make sense.

Step 3: Perform Manual Testing

Manually check:

• Keyboard-only navigation
• Visible focus
• Skip links
• Zoom and responsive reflow
• Heading hierarchy
• Forms and error recovery
• Colour-dependent information
• Time limits
• Dialog and menu behaviour
• Captions and transcripts

Step 4: Test With Assistive Technologies

Use representative combinations such as:

• NVDA with Chrome or Firefox on Windows
• VoiceOver with Safari on macOS or iOS
• TalkBack with Chrome on Android

Check whether users can understand the page, discover controls and finish priority journeys. Testing with people with disabilities provides insights that tools and internal teams may miss.

---

How Should Accessibility Issues Be Prioritised?

Use impact, frequency and reach rather than fixing issues in the order a scanner reports them.

Priority	Typical condition	Example
Critical	Prevents a core task	Checkout cannot be completed by keyboard
High	Blocks content or controls for many users	Form fields have no accessible labels
Medium	Creates significant difficulty but has a workaround	Focus order is confusing
Low	Limited impact or affects secondary content	Decorative icon is announced unnecessarily

Resolve shared component failures first. Then address critical journeys, high-traffic templates, content issues and lower-impact defects.

For a broader quality review, combine accessibility findings with the website evaluation checklist and web application security checklist.

---

How Can You Maintain Accessibility?

Accessibility is an ongoing product requirement, not a one-time remediation project.

• Add accessibility criteria to design and development acceptance requirements.
• Test reusable components before adding them to the design system.
• Include automated accessibility tests in CI/CD where practical.
• Train content editors to use headings, links and alt text correctly.
• Review accessibility during design, code review and QA.
• Retest after major releases, redesigns or third-party changes.
• Track defects with owners, severity and target resolution dates.
• Publish an accessibility statement with a feedback method.
• Include people with disabilities in usability research where possible.
• Schedule periodic audits based on release frequency and risk.

If remediation requires design-system, frontend or CMS changes, an experienced web development company can help convert audit findings into maintainable components and testing practices.

---

---

Conclusion

An effective ADA website compliance checklist goes beyond missing alt text and scanner scores. It examines whether people with disabilities can understand the content, operate every control, recover from errors and complete essential tasks.

Use WCAG as a technical framework, combine automated and manual testing, prioritise barriers by user impact and incorporate accessibility into ongoing design, development and content processes. When legal interpretation is required, seek advice based on your organisation, jurisdiction and services.

---

Frequently Asked Questions

Is WCAG compliance the same as ADA compliance?

No. WCAG is a technical accessibility standard, while the ADA is a United States civil rights law. WCAG is commonly used as a benchmark for evaluating accessibility, but meeting a WCAG target should not automatically be presented as a definitive legal conclusion.

Which WCAG version should a website use?

W3C encourages the use of WCAG 2.2. Many organisations target Level AA unless a law, regulation, procurement requirement or contract specifies another version or level.

Can an automated checker confirm that my website is ADA compliant?

No. Automated tools can identify some technical issues, but they cannot evaluate every success criterion or determine the legal status of a website. Combine automated scanning with manual, assistive technology and user testing.

How do I check whether my website is accessible?

Start with automated scans, then test keyboard access, focus order, zoom, reflow, forms, multimedia and complete user journeys. Test representative pages with screen readers and include users with disabilities where possible.

How often should a website accessibility audit be performed?

Retest after major releases, redesigns, template changes and third-party integration updates. Organisations with frequent releases should include accessibility checks in routine development and schedule broader audits based on risk and change frequency.

Does an accessibility overlay make a website compliant?

An overlay alone should not replace accessible design, semantic code, manual testing and remediation. Evaluate whether the underlying website and complete user journeys remain usable with assistive technologies.

Do PDFs and third-party tools need to be accessible?

They may be part of the user’s complete digital journey. Review downloadable documents, payment systems, booking widgets, chat tools and other integrations rather than limiting the audit to pages controlled directly by your team.

---