Accessibility Audit Checklist: Your 2026 WCAG Guide

What an accessibility audit checklist actually covers

An accessibility audit checklist is a structured set of verification steps that measures how well a website meets the Web Content Accessibility Guidelines (WCAG), the internationally recognized standard for digital accessibility. If you're running a website accessibility audit, this checklist is your backbone, not a nice-to-have add-on.

WCAG organizes compliance into three levels:

• Level A covers the minimum requirements. Without these, some users simply cannot access your content at all.
• Level AA is the recommended target for most organizations. It's the level referenced by the ADA and Section 508, and ADA Title II now requires WCAG 2.1 AA compliance with enforcement deadlines approaching in the next few years.
• Level AAA represents optimal accessibility. Achieving it fully across an entire site is rarely practical, but individual criteria are worth pursuing where feasible.

A solid checklist for digital accessibility typically covers these core areas:

• Perceivable content (text alternatives, contrast, captions)
• Operable interfaces (keyboard access, focus management, timing)
• Understandable interactions (forms, error messages, consistent navigation)
• Robust code (semantic HTML, ARIA, assistive technology compatibility)

One honest caveat: no checklist can guarantee full accessibility. Real-world barriers often only surface through assistive technology testing and feedback from people with disabilities. Think of this checklist as a floor, not a ceiling.

***

1. Content-related checks you need to run first

Perceivable content is where most audits begin, and where the most visible failures hide. These checks verify that every user, regardless of ability, can actually receive the information your site presents.

• Alt text on images: Every meaningful image needs descriptive alternative text. Decorative images should carry an empty alt="" attribute so screen readers skip them cleanly.
• Color contrast: Normal text requires a 4.5:1 contrast ratio; large text (18pt or 14pt bold) requires 3:1. Tools like the WebAIM Color Contrast Checker make this fast to verify.
• Color as the only signal: Check that color alone never conveys meaning. If a form field turns red to signal an error, there must also be a text label or icon explaining the problem.
• Text resize: Zoom the browser to 200% and confirm that text reflows without horizontal scrolling and without content loss.
• Captions and transcripts: Videos need synchronized captions. Audio-only content needs a text transcript. Pre-recorded video with meaningful visuals needs an audio description track.
• Reading level and plain language: Content should be written at a level appropriate for the audience. Dense jargon without explanation fails WCAG 3.1.5 (AAA) and frustrates real users.
• Link purpose: Every link must make sense out of context. "Click here" tells a screen reader user nothing; "Download the 2026 accessibility report" does.

WCAG success criteria to reference: 1.1.1 (Non-text Content), 1.3.3 (Sensory Characteristics), 1.4.3 (Contrast Minimum), 1.4.4 (Resize Text), 1.2.2 (Captions), 1.2.3 (Audio Description).

***

2. Global code and keyboard accessibility checks

Keyboard accessibility is the single most common failure category in professional audits. If a user cannot operate your site with a keyboard alone, you've locked out people who rely on switch controls, sip-and-puff devices, and screen readers.

• All interactive elements reachable by keyboard: Buttons, links, modals, dropdowns, and custom widgets must all receive focus via the Tab key. If you built a custom component in JavaScript, it needs keyboard support built in.
• Logical tab order: Tab through the page and confirm focus moves in a sequence that matches the visual layout. A focus order that jumps around the page is disorienting and fails WCAG 2.4.3.
• Visible focus indicators: Every focused element must display a clearly visible outline. CSS that removes the default browser outline without replacing it is one of the most common accessibility violations on the web.
• No keyboard traps: Users must be able to move focus into and out of every component. Modal dialogs are a frequent trap; test that pressing Escape closes them and returns focus to the triggering element.
• Semantic HTML and ARIA: Use native HTML elements where they exist (<button>, <nav>, <main>, <header>). Add ARIA roles and landmarks only when native HTML falls short, and validate that ARIA usage is correct, since incorrect ARIA is worse than no ARIA.
• Skip navigation links: A "Skip to main content" link at the top of each page lets keyboard users bypass repetitive navigation blocks.
• Timing and motion: If your site uses auto-advancing carousels or timed sessions, users need controls to pause, stop, or extend them. Parallax and animation effects should respect the prefers-reduced-motion media query.
• Target size: Interactive targets should meet the WCAG 2.5.5 recommendation of at least 44x44 CSS pixels to support users with motor impairments.

WCAG success criteria to reference: 2.1.1 (Keyboard), 2.1.2 (No Keyboard Trap), 2.4.3 (Focus Order), 2.4.7 (Focus Visible), 4.1.2 (Name, Role, Value).

***

3. Forms, tables, and controls: the understandability layer

Forms are where accessibility failures cost real users real outcomes. A checkout form that screen readers can't navigate means a lost sale. A government form with unlabeled fields means someone can't access a service they need.

• Labeled inputs: Every form field must have a programmatically associated <label>. Placeholder text alone does not count as a label; it disappears when the user starts typing.
• Error identification: When a form submission fails, the error message must identify the specific field and explain what went wrong. "Please correct the errors below" with no further detail fails WCAG 3.3.1.
• Error suggestions: Where possible, tell users how to fix the error. "Enter a date in MM/DD/YYYY format" is far more useful than "Invalid date."
• Assistive technology compatibility: Forms must not block password managers or autofill, and authentication steps should not require cognitive tasks that assistive technologies cannot support.
• Table markup: Data tables need <th> elements with appropriate scope attributes. Complex tables benefit from a <caption> and, where needed, headers attributes linking cells to their headers.
• No layout tables: Tables used purely for visual layout should use role="presentation" so screen readers don't announce them as data structures.
• Consistent navigation: Repeated navigation elements must appear in the same order across pages. Users who rely on spatial memory to navigate are thrown off when menus shift position.
• Controls with clear names: Every button and control needs an accessible name. An icon-only button with no aria-label is invisible to screen reader users.

WCAG success criteria to reference: 1.3.1 (Info and Relationships), 3.3.1 (Error Identification), 3.3.2 (Labels or Instructions), 3.3.3 (Error Suggestion), 2.4.6 (Headings and Labels).

***

4. Audio and video media accessibility checks

Media is often the most neglected area in a web accessibility checklist, partly because it requires production effort beyond code changes. But WCAG is clear: time-based media must be perceivable by users who cannot hear or see it.

• Synchronized captions for video: Pre-recorded video with audio needs accurate, synchronized captions. Auto-generated captions from platforms like YouTube are a starting point, but they require human review for accuracy, especially with technical terminology or accents.
• Text transcripts for audio: Audio-only content (podcasts, recorded calls) needs a full text transcript. The transcript should capture all spoken content, including speaker identification where relevant.
• Audio descriptions: Pre-recorded video that conveys meaningful information through visuals alone needs an audio description track or a text alternative that describes those visuals. A talking-head interview may not need one; a product demo almost certainly does.
• Media player controls: The play, pause, stop, and volume controls on embedded players must be keyboard accessible and labeled for screen readers. Many third-party players fail this out of the box.
• No autoplay: Video or audio that plays automatically and lasts more than three seconds must offer a mechanism to pause or stop it. Autoplaying audio is particularly disruptive for screen reader users.
• Live captions: Live video content (webinars, live streams) needs real-time captions. This is a Level AA requirement under WCAG 1.2.4.

WCAG success criteria to reference: 1.2.1 (Audio-only and Video-only), 1.2.2 (Captions, Pre-recorded), 1.2.3 (Audio Description), 1.2.4 (Captions, Live), 1.2.5 (Audio Description, Pre-recorded).

***

5. How to combine automated tools with manual testing

Automated accessibility testing tools catch about 30–40% of accessibility issues, mostly mechanical errors like missing alt text or contrast failures. The remaining 60–70% require human judgment.

What automated tools do well:

• Detecting missing or empty alt attributes at scale
• Flagging contrast ratio failures across hundreds of pages
• Identifying missing form labels and ARIA misuse
• Running on every code commit so regressions surface immediately

Tools like axe-core, Lighthouse, and Pa11y integrate directly into CI/CD pipelines, which means your team catches new issues during development rather than after launch. The WAVE browser extension from WebAIM is a fast option for page-by-page manual spot checks.

What only manual testing catches:

• Keyboard traps that automated scanners cannot simulate
• Logical focus order problems that require a human to navigate
• Screen reader announcements that are technically present but contextually wrong
• Cognitive load issues and confusing interaction patterns

The Section 508 guidance from GSA frames this well: accessibility conformance belongs inside the development lifecycle, not bolted on at the end. Schedule quarterly manual audits for complex workflows and run automated scans weekly or monthly as a baseline.

User testing with people with disabilities adds a third layer that neither automation nor expert manual review fully replicates. Real users surface barriers that trained auditors miss because they've internalized workarounds.

Prioritizing what you find: Not every issue carries equal weight. Rank findings by two factors: how many users are affected, and how severely. A missing skip link affects every keyboard user on every page. A missing audio description on one archived video affects a narrower audience. Fix the high-impact, high-frequency issues first.

Documenting your findings: A good audit report names the specific element, the WCAG success criterion it fails, the severity level, and a recommended fix. Vague reports ("improve accessibility") produce no action. Specific ones do.

Continuous monitoring matters because websites change constantly. A new content editor can introduce an unlabeled image. A plugin update can break keyboard navigation. Scheduled audits and automated scans keep compliance from drifting.

Pro Tip: Set up axe-core or a similar linter in your CI pipeline to block merges that introduce new WCAG failures. This prevents the audit backlog from growing faster than your team can address it, and it shifts accessibility left into the development process where fixes cost far less.

***

Key Takeaways

A complete website accessibility audit requires both automated scanning and manual expert testing, organized against WCAG 2.1 AA criteria, with continuous monitoring to stay compliant as your site evolves.

***

Your site's accessibility starts at the foundation

Running through an a11y audit guide tells you what's broken. Fixing it at the code level, and keeping it fixed, is a different challenge entirely. That's where the build matters as much as the checklist.

Sosei builds websites with WCAG 2.1 AA compliance baked in from day one, not retrofitted after launch. Every site SOSEI delivers includes semantic HTML structure, keyboard-accessible components, proper ARIA implementation, and contrast-compliant design, across many industries. If your current site is failing an accessibility evaluation and you're looking at a rebuild anyway, that's the right moment to get it right structurally.

Start with a free 40-point audit at SOSEI and see exactly where your site stands before you commit to anything.

Recommended

• WCAG 2.1 AA: The Accessibility Standard Every Modern Website Must Meet — SOSEI Blog
• Security & Compliance — GDPR, WCAG, SSL Built In | SOSEI
• SOSEI Blog — SEO, GEO, AEO, GDPR, AI Discoverability
• GDPR Cookie Banner Requirements in 2026: What's Compliant, What Isn't — SOSEI Blog