What Is an Accessibility Audit? How to Check If Your Website Is WCAG Compliant

<p>According to the latest WebAIM Million report, <strong>56 million distinct accessibility errors</strong> were detected across one million home pages — an average of 56 errors per page. That means the overwhelming majority of websites are actively failing users with disabilities every single day. If you are a website owner, developer, or compliance manager wondering whether your site is WCAG compliant, the answer almost certainly involves running a proper accessibility audit. The question is: what does that actually mean, and how do you do it right?</p> <h2>Why Accessibility Audits Have Become Non-Negotiable</h2> <p>Web accessibility has moved well beyond the realm of good intentions. It is now a legal requirement in an expanding number of jurisdictions, and the consequences of non-compliance are concrete and measurable. <strong>Over 4,000 web accessibility lawsuits</strong> were filed in the United States in 2024, and the trend continues to rise. Courts in the US have consistently held that websites of businesses open to the public must be accessible under ADA Title III. Meanwhile, the European Accessibility Act became enforceable across all EU member states in June 2025, extending requirements beyond government sites to cover banking apps, e-commerce platforms, SaaS products, and more.</p> <p>The numbers paint a stark picture. Around 16% of the global population — approximately 1.3 billion people — lives with some form of disability. In the United States alone, roughly one in four adults has a disability. These are not edge-case users. They are customers, employees, students, and citizens who encounter barriers on websites that most developers never even think about.</p> <p>Beyond the legal risk, there is a measurable business case. Accessible websites perform better in search engines, because the same structural clarity that helps screen readers — semantic headings, descriptive alt text, clean markup — also helps crawlers. Inclusive design consistently improves usability for everyone: captions benefit people in noisy environments, high contrast helps people in bright sunlight, and keyboard navigation benefits power users. An accessibility audit is the first step toward capturing all of these benefits.</p> <p>One more important shift: ADA Title II now explicitly requires web accessibility for US state and local government entities, with the DOJ adopting WCAG 2.1 Level AA as the technical standard. Entities serving populations of 50,000 or more face a compliance deadline of April 26, 2026. If you work with public-sector clients or operate in regulated industries, auditing is no longer optional — it is urgent.</p> <h2>What Exactly Is a WCAG Accessibility Audit?</h2> <p>A web accessibility audit is a systematic evaluation of your website's compliance with the Web Content Accessibility Guidelines (WCAG) — the internationally recognized technical standard for digital accessibility, developed by the W3C. In practice, an audit identifies specific barriers that prevent users with disabilities from perceiving, understanding, navigating, and interacting with your content. It maps those barriers against the WCAG success criteria, assigns severity levels, and produces a remediation roadmap.</p> <p>WCAG is currently in version 2.2, published in late 2023 and formally reaffirmed by the W3C in May 2025 as the highest standard for web accessibility. It includes nine new success criteria over WCAG 2.1, covering areas such as keyboard focus visibility, minimum touch target sizes, dragging movement alternatives, and consistent help mechanisms. Importantly, WCAG 2.2 is backwards compatible — meeting 2.2 means you also meet 2.1 and 2.0.</p> <p>WCAG is organized around three conformance levels. <strong>Level A</strong> covers the most critical barriers — failures at this level make content completely unusable for some users. <strong>Level AA</strong> is the target mandated by most accessibility laws worldwide, including the ADA, the European Accessibility Act, and Section 508. <strong>Level AAA</strong> represents the highest bar and is typically aspirational rather than legally required. When someone says their site is "WCAG compliant," they almost always mean WCAG 2.1 or 2.2, Level AA.</p> <p>WCAG is built on four core principles, often remembered by the acronym <strong>POUR</strong>: content must be <em>Perceivable</em> (users can sense it), <em>Operable</em> (users can interact with it), <em>Understandable</em> (users can comprehend it), and <em>Robust</em> (it works reliably with assistive technologies). Every success criterion maps back to one of these four principles, and a thorough audit checks conformance against all of them.</p> <h2>The Most Common Failures Audits Uncover</h2> <p>Roughly 96% of all detected accessibility errors fall into just six categories. Knowing what to look for is the fastest way to prioritize your audit effort:</p> <ul> <li><strong>Low contrast text.</strong> This is consistently the most common failure. Nearly 84% of home pages have text that falls below the WCAG 2 AA contrast threshold of 4.5:1 for normal text. Auditors check foreground-to-background color ratios using tools like the TPGi Colour Contrast Analyser.</li> <li><strong>Missing alternative text.</strong> Over 16% of all home page images lack any alt attribute, leaving screen reader users with no way to understand image content. Linked images without alt text are especially damaging — they become meaningless navigation targets.</li> <li><strong>Empty links.</strong> Links that contain no visible text and no accessible name create dead ends for keyboard and screen reader users, who cannot determine where the link goes.</li> <li><strong>Missing form input labels.</strong> Forms without programmatically associated labels are unusable for screen reader users. This includes both visible labels and hidden labels using <code>aria-label</code> or <code>aria-labelledby</code>.</li> <li><strong>Empty buttons.</strong> Icon-only buttons without an accessible name — common in navigation and sliders — leave non-visual users unable to identify what the button does.</li> <li><strong>Missing document language.</strong> The <code>lang</code> attribute on the <code>&lt;html&gt;</code> element tells screen readers which language to use. Its absence causes mispronunciation and disorientation for users relying on text-to-speech.</li> </ul> <blockquote>Audits consistently reveal that the most damaging failures are also the easiest to fix. Low contrast, missing alt text, and unlabeled form fields can often be remediated in days, not months.</blockquote> <p>Beyond these six, a thorough audit will also catch missing skip navigation links (which force keyboard users to tab through every header element on every page), improper heading hierarchy, inaccessible modals and dialogs that trap focus incorrectly, videos without captions, PDFs without tagged structure, and custom JavaScript widgets that do not expose accessible roles and states via ARIA.</p> <h2>How to Conduct an Accessibility Audit: Step by Step</h2> <p>A proper accessibility audit is not a single scan — it is a multi-stage process that combines automated tools with expert human judgment. Here is how to approach it systematically:</p> <h3>Step 1: Define the Scope</h3> <p>Before running a single test, decide what you are auditing. For a large site, testing every page is impractical. Instead, apply the WCAG-EM (Website Accessibility Conformance Evaluation Methodology) approach developed by the W3C: define a representative sample that covers all unique page templates, all significant user journeys, and all distinct content types. A sample for an e-commerce site might include the homepage, a category page, a product detail page, the cart, checkout flow, account login, contact form, and a blog post. Make sure dynamic states are included — open menus, form error messages, modal dialogs, and loaded search results all need evaluation.</p> <h3>Step 2: Run Automated Scans</h3> <p>Automated tools are the foundation of any efficient audit. They scan your HTML quickly, flag unambiguous rule violations, and give you a baseline issues list. Key tools include:</p> <ul> <li><strong>axe DevTools</strong> (browser extension or CLI) — widely used, low false-positive rate, integrates with CI/CD pipelines</li> <li><strong>WAVE</strong> (WebAIM) — annotates pages visually with error icons, making it intuitive for non-technical team members</li> <li><strong>Lighthouse</strong> (built into Chrome DevTools) — provides an accessibility score alongside performance and SEO metrics</li> <li><strong>Colour Contrast Analyser</strong> (TPGi) — picks any color on screen and checks it against WCAG thresholds</li> <li><strong>PAC 2024</strong> — dedicated PDF accessibility checker for downloadable documents</li> </ul> <p>A critical limitation: automated tools can only detect between 30% and 40% of WCAG issues. They excel at flagging rule-based failures like missing attributes, invalid ARIA roles, and contrast ratios. But they cannot judge whether alt text is <em>meaningful</em>, whether a form is logically structured, or whether a user can actually complete a task. This is why automation is Step 2, not the whole audit.</p> <h3>Step 3: Manual Expert Testing</h3> <p>Manual testing by a knowledgeable human — or ideally a team — is where the depth of an audit is determined. This includes:</p> <ul> <li><strong>Keyboard-only navigation.</strong> Unplug the mouse and try to complete every core user journey using only Tab, Shift+Tab, Enter, Space, and arrow keys. Can you reach every interactive element? Is the focus indicator always visible? Does focus ever disappear into a component?</li> <li><strong>Screen reader testing.</strong> Use NVDA with Chrome or Firefox on Windows, and VoiceOver with Safari on macOS and iOS. Navigate by headings, landmarks, links, and forms. Does the page make sense without visual context? Are all interactive elements announced correctly?</li> <li><strong>Visual and cognitive review.</strong> Check heading hierarchy for logical structure, verify that error messages are descriptive and associated with the correct field, confirm that time-based media has captions and transcripts, and review that instructions do not rely solely on color, shape, or position.</li> <li><strong>Code inspection.</strong> Review HTML semantics, ARIA usage, focus management in custom widgets, and landmark regions. A modal that does not trap focus, or an ARIA live region that fires on every keystroke, will only be caught at this level.</li> </ul> <h3>Step 4: Assistive Technology Testing with Real Users</h3> <p>The gold standard — and often the most revealing stage — is testing with actual users who rely on assistive technologies daily. People who use screen readers, switch access devices, or voice control software navigate in ways that even expert manual testers do not fully replicate. Including disabled users in your evaluation surfaces real-world friction that tools and checklists simply cannot anticipate.</p> <h3>Step 5: Document and Prioritize Findings</h3> <p>A raw list of failures is not an audit report — it is a starting point. A useful audit document should specify: the affected URL or component, the WCAG success criterion violated, the severity (critical, high, medium, low), the impact on affected users, and specific remediation guidance with code examples where applicable. Priority should be assigned based on user impact first, not technical convenience. A broken form label that prevents checkout is more urgent than a suboptimal heading level on a blog sidebar.</p> <h3>Step 6: Remediate, Validate, and Monitor</h3> <p>Once fixes are implemented, validate them — do not assume the remediation worked. Retest each fix with the same combination of tools and manual checks used during the original audit. After achieving a baseline level of conformance, put continuous monitoring in place. New content, CMS updates, and third-party scripts can introduce regressions at any time. Treat accessibility like security: something you maintain, not something you achieve once and forget.</p> <h2>Automated Scans vs. Full Audits: Understanding the Difference</h2> <p>This distinction matters enormously, especially in a legal context. An automated scan runs a rule-based check against your rendered HTML. It takes seconds or minutes and returns a list of detected violations. It is excellent for catching the obvious, high-volume issues and for integrating into CI/CD workflows to prevent new regressions from shipping. Many overlay and widget products — including accessibility tools — offer automated scanning dashboards as part of their feature set, and these are genuinely useful for ongoing monitoring.</p> <p>A full audit, by contrast, evaluates your site against every applicable WCAG success criterion using a combination of automated scanning, manual expert review, screen reader testing, and keyboard-only navigation. A comprehensive audit combining automated and manual methods can surface over 90% of accessibility issues, compared to the 30–40% ceiling of automation alone. If you face a legal demand letter, procurement requirement, or regulatory inquiry, only a full audit produces the documentation you need.</p> <p>Many organizations use a practical hybrid strategy: automated scans run continuously in CI/CD to catch regressions early, while a full manual audit is conducted annually or after significant site redesigns. This balances thoroughness with efficiency and keeps compliance manageable over time.</p> <blockquote>No tool alone can determine if a site meets accessibility standards. Knowledgeable human evaluation is required to determine if a site is genuinely accessible. — W3C Web Accessibility Initiative</blockquote> <h2>What to Do with Audit Results: Remediation Planning</h2> <p>A completed audit is only valuable if it drives action. How you prioritize the remediation work matters as much as identifying the issues in the first place. A practical framework for remediation prioritization looks like this:</p> <ol> <li><strong>Critical (fix immediately):</strong> Issues that completely block users from completing core tasks — a broken checkout form, an inaccessible login modal, a navigation menu unreachable by keyboard. These represent the highest legal risk and the largest user impact.</li> <li><strong>High (fix within the current sprint or release cycle):</strong> Issues that significantly impair usability for disabled users but do not fully block them — missing alt text on product images, low contrast on body text, unlabeled icon buttons throughout the interface.</li> <li><strong>Medium (scheduled remediation):</strong> Issues that cause friction but have workarounds — inconsistent focus indicators, missing skip links, suboptimal heading hierarchy.</li> <li><strong>Low (backlog with defined owner):</strong> Issues that are best-practice improvements but unlikely to affect usability in most cases — AAA-level enhancements, minor ARIA verbosity improvements.</li> </ol> <p>Document your remediation plan and timeline, even before all fixes are complete. Regulators and courts generally view demonstrated, ongoing, good-faith improvement favorably compared to inaction. If you receive a demand letter, having an audit report plus a remediation schedule in hand is a far stronger position than having no documentation at all.</p> <p>Overlay widgets and SDK tools — like the one offered by Accsible — can play a meaningful role in the remediation phase. They can surface immediate fixes for a significant portion of common issues (especially visual preferences like contrast, font size, and spacing) while your development team works through deeper code-level remediations. The key is to understand what overlays solve well and to use them as part of a layered strategy, not as a replacement for code-level fixes on critical barriers.</p> <h2>How Often Should You Run an Accessibility Audit?</h2> <p>A one-time audit is a snapshot of your site on a particular day. Websites are living products — content changes, third-party scripts update, components get replaced, and new features ship. Each of these events can introduce new accessibility barriers. A sustainable accessibility program typically looks like this:</p> <ul> <li><strong>Continuous automated scanning</strong> integrated into your CI/CD pipeline or via a monitoring dashboard, catching regressions before they reach production</li> <li><strong>Quarterly manual spot-checks</strong> on high-traffic and high-risk pages (checkout, login, contact forms, key landing pages)</li> <li><strong>Annual full audit</strong> conducted by qualified accessibility experts, especially after major redesigns or platform migrations</li> <li><strong>Audit at design phase</strong> for any new major feature or redesign — accessibility is significantly cheaper to build in than to retrofit</li> </ul> <p>The most cost-effective approach is to shift accessibility left — integrating it into the design and development process from day one rather than treating it as a post-launch compliance exercise. Developers who understand WCAG requirements catch issues at the source. Designers who know about color contrast and touch target sizes make accessible choices by default. An audit then becomes a quality gate rather than an emergency intervention.</p> <h2>Key Takeaways</h2> <ul> <li><strong>Most websites fail WCAG.</strong> Over 95% of home pages have detectable accessibility errors, and the six most common failures — low contrast, missing alt text, empty links, missing form labels, empty buttons, and missing document language — account for the vast majority. These are all fixable.</li> <li><strong>Automated tools are necessary but not sufficient.</strong> Automated scanners catch 30–40% of WCAG issues at best. A complete audit requires keyboard testing, screen reader testing, and expert human review of code and UX flows.</li> <li><strong>WCAG 2.2 Level AA is the target.</strong> It is the standard referenced by the ADA, the European Accessibility Act, Section 508, and most other accessibility frameworks worldwide. Aiming for 2.2 AA means you cover all lower versions automatically.</li> <li><strong>Remediation needs a priority framework.</strong> Start with issues that block core user journeys entirely, then work through high-impact, high-frequency issues. Document everything — your audit report and remediation plan are your best legal defense.</li> <li><strong>Accessibility is ongoing, not one-and-done.</strong> Combine continuous automated monitoring with periodic manual audits and shift accessibility into your design and development process from the start. An overlay widget like Accsible can bridge gaps while deeper remediations are underway.</li> </ul>