The Ultimate Website Accessibility Audit Checklist (2026)

The Ultimate Website Accessibility Audit Checklist (2026)

A website audit is only as good as the checklist behind it. This guide brings together a practical, end-to-end accessibility audit into 11 essential checks, each mapped to its WCAG 2.1 conformance level so you know exactly what's required for ADA compliance and a genuinely inclusive experience. Use it to audit a new build, remediate an existing site, or brief a developer.

TL;DR: Work through all 11 checks below - keyboard, screen reader, alt text, contrast, semantic structure, forms, multimedia, responsive/zoom, link clarity, ARIA, and legal policy. Items marked Level A are baseline requirements; Level AA items are the standard most laws (including the ADA) expect. Then move from a one-time audit to continuous monitoring.

How to Use This Checklist

Each item lists what to check, why it matters, and its WCAG 2.1 level. Combine automated tools (to catch contrast, alt text, and structural issues at scale) with manual testing (for keyboard flow, screen reader experience, and judgment-based criteria). Treat Level A as non-negotiable and Level AA as your target.

1. Keyboard Navigation and Focus Management (WCAG 2.1 Level A)

Every interactive element - links, buttons, forms, menus, modals - must be operable with the keyboard alone, in a logical order, with a clearly visible focus indicator and no keyboard traps. This is essential for users who can't use a mouse, and it underpins SPA and widget accessibility.

This ensures that users who cannot operate a mouse, including those with motor disabilities or who rely on assistive technologies, can navigate and interact with every part of your website. The core principle is that any action achievable with a mouse must also be achievable with a keyboard.

This involves two key components: navigation (moving between elements) and focus management (knowing where you are). A logical focus order, typically following the visual layout from top-to-bottom and left-to-right, is crucial for an intuitive user experience.

Why It Matters

Proper keyboard support is a non-negotiable requirement under WCAG 2.1.1 (Keyboard). Without it, entire user groups are locked out of your digital content. Companies like Google and GitHub have set a high standard, demonstrating how comprehensive keyboard support enhances usability for all users, including power users who prefer keyboard shortcuts for efficiency.

How to Check It

• Manual Test: Put your mouse aside. Use the Tab key to move forward through interactive elements and Shift+Tab to move backward. Use Enter to activate links/buttons and the Spacebar to toggle checkboxes or buttons.
• Automated Tools: While manual testing is essential, tools like axe DevTools can help identify elements that are not focusable or lack a visible focus indicator.

Pass/Fail Criteria & Remediation

• Pass: You can access and operate every interactive element, including menus, forms, and modals, in a logical sequence without using a mouse. A highly visible focus indicator (e.g., a colored outline) is always present.
• Fail: You get "stuck" in a section (a "keyboard trap"), cannot see where the focus is, or cannot reach an element that is clickable with a mouse.
• Remediation:
  • "Skip to main content" link: Implement this as the first focusable element on every page to help users bypass repetitive navigation.
  • CSS focus-visible: Use the :focus-visible pseudo-class to style focus indicators, ensuring they appear for keyboard users but not necessarily for mouse clicks.
  • Semantic HTML: Use native <button>, <a>, and <input> elements, as they have built-in keyboard accessibility. Avoid using non-interactive elements like <div> or <span> for buttons without adding appropriate ARIA roles and tabindex attributes.

2. Screen Reader Compatibility (WCAG 2.1 Level A)

Test with a screen reader (NVDA, VoiceOver, or JAWS) to confirm content is announced in a meaningful order, controls expose accessible names and roles, and dynamic updates are communicated. Automated tools can't fully judge this - manual testing is required.

These assistive technologies convert on-screen text and interface elements into speech or braille, enabling users with visual impairments to navigate the web. For a screen reader to work effectively, the underlying code must be structured semantically.

This involves providing context that isn't visually apparent. Elements like headings, lists, links, and form controls must be coded correctly so the screen reader can announce their purpose and state. For example, a screen reader should announce "button, submit" for a submit button, not just "submit." This is a fundamental check in any comprehensive website audit checklist.

Why It Matters

Screen reader compatibility is a core requirement of WCAG 2.1.1 (Text Alternatives) and 4.1.2 (Name, Role, Value). Without it, a significant portion of the population cannot access your information or services. Organizations like the BBC and LinkedIn have invested heavily in screen reader testing, proving that a well-structured site not only meets compliance standards but also creates a more robust and usable experience for everyone.

How to Check It

• Manual Test: The most reliable method is to test with real screen readers. Download NVDA (free), or use built-in tools like VoiceOver (macOS/iOS) or Narrator (Windows). Navigate your site using only the keyboard and listen to how the content is announced.
• Automated Tools: Browser extensions like WAVE or axe DevTools can detect many common issues, such as missing alt text on images or improper ARIA attribute usage, which directly impact the screen reader experience.

Pass/Fail Criteria & Remediation

• Pass: All content is read logically, interactive elements are clearly identified, images have descriptive alt text, and users can complete key tasks (like filling out a form) without confusion.
• Fail: The screen reader announces generic or confusing information (e.g., "click here"), content is read out of order, or critical elements are completely silent and skipped over.
• Remediation:
  • Semantic HTML: Prioritize native HTML elements like <nav>, <main>, <h1>-<h6>, and <button> over generic <div>s. This provides built-in accessibility.
  • ARIA for Context: Use ARIA (Accessible Rich Internet Applications) roles and attributes like aria-label or aria-describedby to add necessary context to custom components, but only when semantic HTML is insufficient.
  • Image Alt Text: Ensure every meaningful image has descriptive alt text. For decorative images, use an empty alt attribute (alt="") so screen readers skip them. For a deeper dive into this topic, you can learn more about screen reader compatibility testing procedures.

3. Text Alternatives for Non-Text Content (WCAG 2.1 Level A)

Provide descriptive alt text for informative images, icons, and complex visuals, and mark purely decorative images so screen readers skip them. Good alt text improves screen reader comprehension and brings SEO benefits.

4. Sufficient Color Contrast and Visual Clarity (WCAG 2.1 Level AA)

Text must meet a contrast ratio of at least 4.5:1 (3:1 for large text), and meaningful non-text elements need 3:1. Never rely on color alone to convey information - pair it with text or icons.

5. Semantic HTML and Heading Structure (WCAG 2.1 Level A)

Use native HTML elements and a logical heading hierarchy (one H1, nested H2/H3) with landmark regions. Proper structure lets assistive technology navigate the page and improves content hierarchy for everyone.

6. Accessible Forms with Labels and Error Identification (WCAG 2.1 Levels A & AA)

Every input needs a programmatically associated label, clear instructions, and accessible error messages that identify the field and explain how to fix it. Don't signal errors with color alone.

7. Multimedia Captions and Transcripts (WCAG 2.1 Levels A & AA)

Provide synchronized captions for video, transcripts for audio, and audio descriptions where visuals carry essential information. This serves deaf and hard-of-hearing users and improves comprehension for all.

8. Responsive, Mobile, and Zoom-Friendly Design (WCAG 2.1 Level AA)

Content must reflow and remain usable up to 200% zoom and across screen sizes, with adequate target sizes and no loss of functionality. Mobile accessibility is now a baseline expectation.

9. Clear Link Text and Navigation (WCAG 2.1 Level A)

Links should make sense out of context (avoid "click here"), navigation should be consistent across pages, and skip links should let keyboard users bypass repetitive blocks.

10. ARIA for Dynamic Content (WCAG 2.1 Level A)

For dynamic and custom components - modals, tabs, accordions, live regions - apply ARIA roles, states, and properties correctly so assistive technology understands them. The golden rule: use native HTML first, and only add ARIA when necessary, because incorrect ARIA is worse than none.

11. Legal Compliance and Policy Documentation

Map your conformance to the standards that apply to you (ADA, WCAG 2.1/2.2 AA, Section 508, EAA), publish an accessibility statement describing your commitment and contact route, and keep records of audits and remediation. Documentation demonstrates good-faith effort and reduces legal risk.

The 11-Point Audit at a Glance

#	Check	WCAG level	Test method
1	Keyboard navigation & focus	A	Manual
2	Screen reader compatibility	A	Manual
3	Text alternatives (alt text)	A	Automated + manual
4	Color contrast	AA	Automated
5	Semantic HTML & headings	A	Automated + manual
6	Accessible forms	A & AA	Manual
7	Multimedia captions/transcripts	A & AA	Manual
8	Responsive & zoom	AA	Manual
9	Link text & navigation	A	Manual
10	ARIA for dynamic content	A	Manual
11	Legal compliance & policy	-	Documentation

Beyond the Checklist: Embracing Continuous Accessibility

An audit is a snapshot; accessibility is ongoing. As you publish content and ship features, new issues appear. Bake these checks into your design and development workflow, schedule automated monitoring to catch regressions, and assign clear ownership. A tool like WebAbility.io can provide continuous scanning and a user-facing widget so your site stays compliant - and inclusive - between formal audits.

Turning Your Audit into Action

Run every page that matters through these 11 checks, log issues by severity and WCAG level, fix the Level A blockers first, then close the Level AA gaps. Re-test, document, and monitor. That's how a one-time checklist becomes a durable standard of accessibility for every visitor.