An accessibility audit checklist is a structured document that guides you through every verification step needed to confirm your website works for people with disabilities. Unlike a vague promise to make things accessible, a checklist turns compliance into concrete yes-or-no questions. Does this image have alt text? Can a keyboard user reach every interactive element? Does the color contrast meet the 4.5:1 ratio? This guide provides over 50 checkpoints organized by the four WCAG principles, plus a workflow for running the audit itself. Whether you are preparing for the European Accessibility Act deadline that took effect in June 2025, the ADA Title II requirements hitting US state governments in April 2026, or simply trying to build a better product, this checklist gives you the structure to get it done.
Why You Need a Structured Audit Checklist
Running an accessibility audit without a checklist is like performing a building inspection from memory. You will catch the obvious problems and miss the subtle ones that actually trip people up.
Automated scanning tools are a good starting point, but they only catch around 30 to 40 percent of WCAG issues. The rest require human judgment. Is this alt text actually descriptive, or does it just say image? Does the tab order make logical sense? Can someone with low vision understand this chart without relying on color alone? A checklist ensures you ask these questions systematically rather than hoping you remember them.
There is also a legal dimension that has sharpened considerably. The European Accessibility Act became enforceable on June 28, 2025, with fines ranging from 5,000 to 300,000 euros depending on the EU member state. In the United States, the DOJ finalized ADA Title II rules requiring WCAG 2.1 AA compliance for state and local government websites, with the first deadline arriving April 26, 2026 for entities serving populations over 50,000. A checklist is your evidence that you took compliance seriously and followed a methodical process.
Beyond legal requirements, there is a business case. Sites that pass accessibility audits tend to perform better in search rankings, convert more users, and face fewer support tickets from people who cannot complete basic tasks. The checklist pays for itself.
Before You Start: Setting Up Your Audit
A good audit begins with scope definition. Trying to test every page on a large site is impractical and unnecessary. Focus on these categories:
High-traffic pages: your homepage, main landing pages, and the top 10 pages by visitor count. These are where accessibility failures affect the most people.
Key user flows: registration, login, checkout, search, and any multi-step forms. Test the complete journey, not individual pages in isolation.
Unique templates: if your site uses 8 different page layouts, test at least one representative page from each template. A bug in a template affects every page that uses it.
Content-heavy pages: blog posts, documentation, and knowledge base articles. These often contain images, tables, embedded videos, and downloadable documents that each need their own accessibility treatment.
For a typical business website with 50 to 200 pages, auditing 10 to 15 representative pages covers the vast majority of template and component variations. Document your page selection and the reasoning behind it. This documentation matters if you ever need to demonstrate due diligence.
Tools You Will Need
You do not need expensive enterprise software to run a thorough audit. Here is a practical toolkit:
Automated scanner: Use our free accessibility checker at web-accessibility-checker.com to get an instant WCAG 2.2 compliance report. It flags issues like missing alt text, contrast failures, and missing form labels across your pages.
Browser DevTools: Chrome and Firefox both include accessibility inspection panels. The Chrome Accessibility tab shows the computed accessibility tree for any element. Firefox has a dedicated Accessibility Inspector.
Screen reader: NVDA is free on Windows. VoiceOver is built into macOS and iOS. TalkBack is built into Android. You need at least one screen reader to verify that your content makes sense when read aloud.
Keyboard: Your actual keyboard. Disconnect your mouse and try to complete your key user flows using only Tab, Shift+Tab, Enter, Space, and arrow keys.
Color contrast analyzer: The Colour Contrast Analyser from TPGi is free and lets you check any color combination against WCAG thresholds.
PDF checker: If your site offers downloadable PDFs, use PAC 2024 (PDF Accessibility Checker) to verify document accessibility.
Principle 1: Perceivable
The first WCAG principle asks: can users perceive the content? Information cannot be invisible to all of a users senses. Here are the checkpoints.
Images and Non-Text Content
Every informative image must have alt text that conveys the same information as the image. Photo of building fails. Headquarters office at 42 Main Street, three-story brick building passes. Decorative images that add no information should have empty alt attributes so screen readers skip them entirely.
Check that complex images like charts, graphs, and infographics have extended descriptions. A pie chart showing market share needs either a long description in the surrounding text or a linked data table.
Verify that all image buttons and linked images have alt text describing the action, not the image. A magnifying glass icon used as a search button should have alt text of Search, not magnifying glass.
CAPTCHAs must provide alternatives. An image-based CAPTCHA needs an audio alternative at minimum. Better yet, use invisible reCAPTCHA or hCaptcha with accessibility mode.
Video and Audio Content
Pre-recorded videos need synchronized captions. Auto-generated captions from YouTube or similar platforms are a starting point but typically contain errors that must be manually corrected, especially for technical terminology.
Pre-recorded audio content needs a text transcript. Podcasts, recorded webinars, and audio instructions all require transcripts.
Pre-recorded video content needs audio descriptions for visual information that is not conveyed through the existing audio track. If a presenter says as you can see on this slide without describing what the slide shows, a blind user misses the content.
Live video with audio needs real-time captions. This typically requires a professional captioning service or AI-powered live captioning with human oversight.
Text and Readability
Normal text under 18pt or 14pt bold needs a contrast ratio of at least 4.5:1 against its background. Large text at 18pt and above or 14pt bold and above needs at least 3:1. Use a contrast checker tool to verify, and pay special attention to text over images or gradients where contrast varies.
The page must remain functional and readable when text is resized up to 200 percent. Test this in your browser with Ctrl+Plus five times to double the text size. Content should reflow without horizontal scrolling at 320 CSS pixels wide, which simulates a 1280px screen at 400 percent zoom.
Do not use images of text when actual text can achieve the same visual effect. Logos are the one exception.
Check that content does not rely on color alone to convey information. A form that marks required fields only with red text fails. Adding an asterisk or the word required alongside the color passes. Charts that distinguish data series only by color need patterns, labels, or other visual differentiators.
Principle 2: Operable
Can users operate the interface? Every function must work for people who use keyboards, screen readers, voice commands, or switch devices.
Keyboard Accessibility
Every interactive element must be reachable and usable with a keyboard alone. Tab through your entire page. Can you reach every link, button, form field, dropdown, modal, and custom widget? Can you activate each one with Enter or Space?
Check for keyboard traps. A keyboard trap occurs when you can tab into an element but cannot tab out of it. Modal dialogs are the most common culprit. When a modal is open, focus should cycle within the modal. When it closes, focus should return to the element that triggered it.
Verify that the tab order follows a logical reading sequence. If your visual layout places a sidebar before the main content, but the tab order sends keyboard users through the main content first, that disconnect confuses people.
Custom components built with div or span elements instead of native HTML need explicit keyboard handling. A div acting as a button needs tabindex of 0, a role of button attribute, and JavaScript handling for both Enter and Space key presses. Native HTML buttons get all of this for free, which is why semantic HTML matters.
Focus Visibility
Every interactive element must have a visible focus indicator when it receives keyboard focus. The default browser outline works. A custom focus style works too, as long as it is clearly visible against the background.
Under WCAG 2.2 criterion 2.4.11, the focused element must not be entirely hidden behind sticky headers, floating buttons, cookie banners, or chat widgets. Tab through your page with all overlays active and watch for focus indicators that disappear behind fixed-position elements.
Never remove focus outlines without providing an equally visible replacement. This single CSS pattern is responsible for more keyboard accessibility failures than almost any other.
Target Size and Touch
WCAG 2.2 criterion 2.5.8 requires interactive targets to be at least 24 by 24 CSS pixels, or to have enough spacing that a 24px circle centered on the target does not overlap adjacent targets. Inline text links within paragraphs are exempt.
Common failures include icon buttons with no padding, close buttons on modals that are only 16 pixels wide, tightly packed pagination links, and social media icon rows. Open DevTools, select each interactive element, and check its computed size.
For any drag-and-drop functionality, WCAG 2.2 criterion 2.5.7 requires a single-pointer alternative. A sortable list needs up and down buttons. A slider needs a text input. A map pin placement needs an address field.
Timing and Motion
If any content moves, blinks, or scrolls automatically for more than 5 seconds, users must be able to pause, stop, or hide it. Auto-advancing carousels, animated banners, and auto-playing video backgrounds all need pause controls.
Nothing on the page should flash more than three times per second. This is a seizure safety requirement with no exceptions.
If there is a time limit on any interaction, such as a session timeout or a timed form, users must be able to turn off, adjust, or extend the time. At least 20 seconds before the time expires, warn the user and provide a simple way to extend.
Principle 3: Understandable
Can users understand the content and how the interface works? Clear language, predictable behavior, and helpful error handling fall under this principle.
Language and Readability
The page must declare its language in the HTML lang attribute. For English pages, use lang en. If a section of the page is in a different language, mark it with its own lang attribute. Screen readers use this to switch pronunciation rules.
Navigation menus and repeated components should appear in the same relative location across pages. WCAG 2.2 adds criterion 3.2.6 requiring that help mechanisms like contact links, chat widgets, and FAQ links stay in a consistent position.
Check that instructions do not rely solely on sensory characteristics. Telling users to click the green button on the right fails because it depends on color perception and visual layout. Click the Submit button works regardless of how the user perceives the page.
Forms and Error Handling
Every form input needs a visible label that is programmatically associated using the for attribute matching the input id. Placeholder text alone is not a label because it disappears when the user starts typing.
When a form submission produces errors, identify the specific fields with errors and describe what went wrong. A generic error message is not enough. A specific message like Email address: please enter a valid email format is actionable.
Provide suggestions for correcting errors when possible. If a date field expects a specific format, say so in the error message.
For any input that causes a legal or financial commitment, provide a way to review, confirm, and correct the submission before it is finalized. Checkout flows should include an order review step.
WCAG 2.2 adds criterion 3.3.7 requiring that information a user already entered in a multi-step process is auto-populated or available for selection if needed again. Do not ask for the same data twice without pre-filling it.
For authentication, WCAG 2.2 criterion 3.3.8 requires that login processes either avoid cognitive function tests or provide alternatives. Concretely: do not block paste on password fields, support password managers, and provide alternatives to puzzle CAPTCHAs.
Principle 4: Robust
Can assistive technologies interpret the content correctly? This principle focuses on clean code and proper use of accessibility APIs.
Semantic HTML and ARIA
Use semantic HTML elements: header, nav, main, footer, article, section, aside. These create landmarks that screen reader users rely on for page navigation. A screen reader user can jump directly to the main content area if you use a main element. Without it, they listen through the entire header and navigation on every page.
Headings must follow a logical hierarchy. One H1 per page, followed by H2s for major sections, H3s for subsections, and so on. Do not skip levels. An H1 followed directly by an H4 creates a confusing structure for screen reader users who navigate by headings.
All interactive elements must have accessible names. Buttons need visible text or an aria-label. Links need descriptive text rather than click here or read more. Form inputs need labels. Icon-only buttons need aria-label attributes.
Use ARIA roles and properties only when native HTML does not provide the needed semantics. A native button element does not need role button. A custom dropdown built from divs does need role listbox and related ARIA attributes. The first rule of ARIA is: do not use ARIA if you can use native HTML instead.
Check that dynamic content updates are announced to screen readers. When content changes without a page reload, such as adding items to a cart, showing validation errors, or loading search results, use aria-live regions to announce the change. Without this, screen reader users have no way to know something happened.
The Complete Checklist: Quick Reference
Here is the full checklist condensed into a scannable format. Use this as your working document during the audit.
Perceivable checks: - All informative images have descriptive alt text - Decorative images have empty alt attributes - Complex images have extended text descriptions - Videos have synchronized captions (manually verified) - Audio content has text transcripts - Text contrast is 4.5:1 minimum (3:1 for large text) - Page is usable at 200% text zoom without horizontal scrolling - Content does not rely on color alone to convey meaning - No images of text are used (except logos)
Operable checks: - All interactive elements are keyboard reachable - No keyboard traps exist - Tab order follows logical reading sequence - Visible focus indicators are present on all interactive elements - Focus is not obscured by sticky or floating elements - Interactive targets meet 24x24 CSS pixel minimum - Drag-and-drop functions have single-pointer alternatives - Auto-moving content has pause/stop controls - No content flashes more than 3 times per second - Time limits can be turned off or extended - Skip navigation link is present and functional
Understandable checks: - Page language is declared in HTML lang attribute - Navigation is consistent across pages - Help mechanisms appear in consistent locations - Instructions do not rely solely on sensory characteristics - All form inputs have visible programmatic labels - Error messages identify specific fields and describe the problem - Multi-step forms do not ask for the same information twice - Authentication does not block password managers
Robust checks: - Semantic HTML landmarks are used (header, nav, main, footer) - Heading hierarchy is logical with no skipped levels - All interactive elements have accessible names - ARIA is used correctly and only when needed - Dynamic content updates use aria-live regions - Page works across major browsers and assistive technologies
How to Prioritize Issues After the Audit
After running through the checklist, you will likely have a list of issues. Not all failures are equally urgent. Here is a practical prioritization framework.
Critical issues block users from completing core tasks entirely. A keyboard trap on a login form means keyboard users cannot log in at all. A missing form label means screen reader users cannot tell what information to enter. Fix these first, regardless of how many pages they affect.
High issues cause significant difficulty but have workarounds. Poor color contrast makes text hard to read for people with low vision but does not completely prevent access. Missing skip navigation forces keyboard users to tab through the entire header on every page, which is tedious but not blocking. These are your second priority.
Medium issues affect usability but do not prevent task completion. An image with vague alt text is better than no alt text. A focus indicator that works but is not very visible is better than no focus indicator at all. Address these in your regular development cycle.
Low issues are best-practice improvements that go beyond strict WCAG requirements. Using aria-describedby to provide additional context on form fields, optimizing reading level, or adding audio descriptions to videos that already have transcripts. These improve the experience but are not compliance blockers.
Document every finding with its severity, the affected page URL, a screenshot, the relevant WCAG criterion, and a recommended fix. This documentation serves as your remediation roadmap and your compliance evidence.
Automating Ongoing Monitoring
An audit is a snapshot. Websites change constantly: new content gets published, features get updated, templates get modified. Without ongoing monitoring, accessibility regressions creep in within weeks.
Set up automated scanning on a schedule. Our accessibility checker lets you run regular scans on your key pages and track changes over time. This catches regressions in the 30 to 40 percent of issues that automated tools detect.
Build accessibility checks into your development workflow. Add testing libraries like axe-core to your CI/CD pipeline. Flag new accessibility violations before code reaches production. This is cheaper and faster than finding issues in periodic audits.
Schedule manual reviews quarterly. Automated tools miss context-dependent issues. A quarterly manual review of your top pages, combined with screen reader testing of key user flows, catches what automation cannot.
Train your content team. Many accessibility issues come from content, not code. Authors who understand how to write good alt text, structure headings properly, and create accessible links prevent issues at the source rather than creating them for auditors to find later.
Track your progress over time. Maintain a log of audit dates, issue counts by severity, and resolution rates. This demonstrates continuous improvement, which matters both for legal compliance and for building a genuinely accessible product.
Legal Requirements to Know in 2026
The legal landscape for web accessibility has tightened significantly. Here are the frameworks most likely to affect your audit.
The European Accessibility Act took effect on June 28, 2025. It applies to private sector companies selling products or services in the EU, covering websites, mobile apps, e-commerce platforms, and digital banking services. The technical standard is EN 301 549, which references WCAG 2.1 Level AA. Fines vary by country: up to 100,000 euros in Germany, up to 300,000 euros in Spain, and up to 250,000 euros in France with additional daily penalties.
ADA Title II now explicitly requires web accessibility for US state and local government entities. The DOJ adopted WCAG 2.1 Level AA as the technical standard. Entities serving populations of 50,000 or more must comply by April 26, 2026. Smaller entities have until April 26, 2027. Federal penalties can reach 150,000 dollars per violation.
ADA Title III continues to drive private sector lawsuits in the United States. While there is no explicit web accessibility regulation under Title III, federal courts have consistently held that websites of businesses open to the public must be accessible. Over 4,000 web accessibility lawsuits were filed in the US in 2024.
Germany BFSG (Barrierefreiheitsstaerkungsgesetz) is the German transposition of the EAA, with specific requirements for digital products and services sold in Germany.
Targeting WCAG 2.2 AA in your audit covers the requirements of all these frameworks, since 2.2 is a superset of 2.1.