Table of Contents
- What a Website Accessibility Audit Actually Evaluates
- When an Audit Is Operationally Warranted
- Step 1: Define Audit Scope With Legal and Traffic Logic
- Step 2: Run Automated Scanning as a Baseline, Not a Conclusion
- Step 3: Conduct Structured Manual Testing
- Step 4: Validate With Assistive Technology
- Step 5: Audit Documents and Multimedia Separately
- Step 6: Build a Remediation Priority Framework
- Step 7: Validate Fixes and Establish Ongoing Governance
- Frequently Asked Questions
1. What a Website Accessibility Audit Actually Evaluates
Website Accessibility Audit: Definition and Scope
A website accessibility audit is a structured conformance evaluation that measures how closely a digital property adheres to WCAG 2.1 Level AA, the technical standard that defines ADA compliance for websites. A complete audit combines automated scanning, expert manual review, and assistive technology testing to surface the full range of access barriers. For organizations running WordPress or Drupal, the audit must evaluate two distinct compliance layers: the platform and template layer controlled by development teams, and the content layer managed by editors and administrators on an ongoing basis. Failures are common at both levels and require separate remediation strategies.
An accessibility audit is not a one-time certification event. It is a diagnostic exercise that produces a prioritized remediation roadmap and establishes a documented baseline for ongoing conformance monitoring. Organizations that treat it as a checkbox exercise consistently face recurring legal exposure because the underlying content and platform governance issues are never addressed systemically.
2. When an Audit Is Operationally Warranted
Audit Triggers: Reactive vs. Proactive
Reactive triggers include receiving an ADA demand letter, a DOJ complaint, or a structured negotiation request from a disability rights organization. At this point, the audit occurs under legal scrutiny, timelines are compressed, and remediation costs are elevated. Documentation produced during a reactive audit may be discoverable in litigation, which makes methodology rigor and documentation quality critically important.
Proactive triggers include platform migrations, major redesigns, significant content expansion initiatives, new third-party integrations, and scheduled annual compliance reviews. Proactive audits allow organizations to control scope, pace, and remediation priority. They also produce documentation that demonstrates good-faith compliance effort, a recognized mitigating factor in ADA enforcement contexts and one that courts have acknowledged in evaluating organizational intent.
For organizations in sectors with concentrated enforcement activity, including those operating under Title II deadlines or Section 508 obligations, waiting for a reactive trigger is consistently the highest-cost approach available.
3. Step 1: Define Audit Scope With Legal and Traffic Logic
A full-site audit of a large WordPress or Drupal property is rarely executable in a single engagement. Scope definition should be driven by a combination of legal exposure logic and user traffic data.
| Scope Priority | Rationale | Examples |
|---|---|---|
| High-traffic pages | Maximum user exposure and highest likelihood of enforcement scrutiny | Homepage, primary navigation destinations, core service pages |
| Transactional interfaces | Failures cause direct harm at service access and conversion points | Forms, registration flows, account portals, checkout sequences |
| Content-heavy sections | Highest density of editor-introduced content-level failures | Resource libraries, publications, course catalogs, news archives |
| Global components | Failures at this layer multiply across every page on the domain | Header, footer, navigation menus, site-wide search |
| Document repositories | Frequently excluded from audits, creating standalone compliance exposure | PDF downloads, annual reports, whitepapers, application forms |
For large sites, a representative sample methodology covering all major template types and interaction patterns is an accepted audit approach under WCAG and is recognized in legal contexts, provided the sampling logic is clearly documented and defensible.
4. Step 2: Run Automated Scanning as a Baseline, Not a Conclusion
Automated scanning tools identify a defined subset of WCAG failures efficiently and at scale. They are the starting point of a professional audit, not its deliverable.
Tools used in professional accessibility engagements include WAVE by WebAIM, Axe by Deque, Lighthouse within Chrome DevTools, and IBM Equal Access Checker. Each tool has different detection strengths and coverage gaps. Running multiple tools against the same pages surfaces a broader range of failures than relying on any single scanner.
According to research published by WebAIM, automated tools detect between 25 and 40 percent of WCAG accessibility failures present on a given page. The remaining failures require human judgment, contextual evaluation, and assistive technology testing to identify.
Key Insights: What Automated Tools Cannot Detect
Meaningful vs. decorative image distinction. Automated tools flag images without alt text. They cannot determine whether alt text that is present is accurate, contextually meaningful, or genuinely descriptive of the image's function on that specific page.
Link text quality in context. A scanner can flag 'click here' as a generic phrase. It cannot evaluate whether a link labeled with a destination name is actually descriptive of what the user will access after following it.
Logical reading order. Tools can parse DOM sequence but cannot determine whether the visual reading order and the programmatic reading order communicate the same meaning to a screen reader user.
Cognitive accessibility failures. Overly complex language, confusing navigation patterns, and unpredictable interface behavior are not detectable by automated scanning and require human evaluation.
Dynamic content behavior. Single-page application behaviors, modal focus management, and live region updates require interaction-based testing that automated crawlers cannot replicate.
5. Step 3: Conduct Structured Manual Testing
Manual testing covers the failure categories that automated tools are structurally unable to detect. Understanding what manual testing covers helps organizational decision-makers set realistic expectations for audit scope, timeline, and resource requirements.
Keyboard operability review: Navigate every page and interactive component using only Tab, Shift+Tab, Enter, Escape, and arrow keys. Every interactive element must be reachable, visibly focused, and fully operable via keyboard alone. Any component that traps keyboard focus is a critical WCAG failure with direct legal exposure. On WordPress and Drupal sites, third-party plugins are frequent sources of keyboard traps that the platform theme does not govern or control.
Heading hierarchy audit: Confirm that heading levels reflect logical document structure and are applied for semantic purpose, not visual styling. A page using H1 followed by H4 has a broken document outline that disrupts screen reader navigation and simultaneously undermines search engine content interpretation.
Focus visibility assessment: WCAG 2.1 requires that keyboard focus indicators are visible at all times during navigation. Many themes suppress the browser's default focus outline for aesthetic reasons without providing a compliant alternative. This is a high-frequency failure across both WordPress and Drupal environments and one of the most commonly cited issues in demand letters.
Form label and error association: Every form input must have a label that is programmatically associated with its field, not merely visually adjacent. Error messages must identify the specific field with the problem and describe the required correction clearly. Generic error notifications do not satisfy WCAG success criteria 3.3.1 and 3.3.3, and they are a consistent source of legal complaints.
6. Step 4: Validate With Assistive Technology
Assistive technology testing is the only reliable method for confirming that ARIA implementations, dynamic content updates, and custom interactive components function correctly for users who depend on them in daily operation.
| Testing Combination | User Population Covered |
|---|---|
| NVDA + Firefox (Windows) | Largest screen reader user base on Windows |
| JAWS + Chrome (Windows) | Enterprise and institutional screen reader standard |
| VoiceOver + Safari (macOS and iOS) | Apple ecosystem users across desktop and mobile |
| TalkBack + Chrome (Android) | Android mobile user base |
Prioritize assistive technology testing on modal dialogs, accordion components, tabbed interfaces, carousels, dropdown navigation, and any element that updates content without a full page reload. These interaction patterns generate the highest volume of real-world accessibility barriers on complex WordPress and Drupal builds.
7. Step 5: Audit Documents and Multimedia Separately
Document and media accessibility is the most commonly scoped-out component of website audits. It represents significant compliance exposure precisely because it is so routinely excluded.
Document and Media Compliance Requirements
PDF Accessibility: An untagged PDF is effectively inaccessible to a screen reader user, regardless of how conformant the surrounding web page is. Compliant PDFs require complete tag trees with logical reading order, alternative text on all meaningful images, a defined document language, properly scoped table headers, and keyboard-navigable form fields throughout. PDFs generated by exporting from Word or InDesign without accessibility remediation are frequently non-compliant by default and require post-export remediation before publication.
Video Captions: Auto-generated captions from YouTube, Vimeo, and similar platforms do not meet WCAG 1.2.2 requirements without human review and correction for accuracy, punctuation, speaker identification, and sound description. Transcripts alone do not satisfy the caption requirement for synchronized media. Both must be present and accurate.
Audio Description: Pre-recorded video content that conveys meaningful visual information requires an audio description track for users who are blind or have low vision. This is a requirement under WCAG 1.2.5 at Level AA and is one of the most consistently overlooked compliance gaps across content-heavy sites on any platform.
8. Step 6: Build a Remediation Priority Framework
Any established site audit will surface more issues than any team can resolve simultaneously. Effective compliance programs require structured prioritization, not a first-in-first-out resolution queue.
| Priority Tier | Criteria | Action Timeline |
|---|---|---|
| Critical | Complete access barrier, keyboard trap, zero assistive technology access | Immediate sprint |
| High | Significant barrier on high-traffic or transactional page; frequently cited in litigation | Next scheduled release |
| Medium | Degraded but not blocked access; affects content comprehension or navigation | Planned remediation cycle |
| Low | Minor failure on low-traffic content; cosmetic or marginal accessibility issue | Backlog with defined deadline |
Build a remediation log that records each issue with its WCAG success criterion reference, severity classification, page location, assigned owner, and target resolution date. This documentation demonstrates a sustained, organized compliance program and carries weight in both regulatory review and legal proceedings as direct evidence of good-faith effort.
9. Step 7: Validate Fixes and Establish Ongoing Governance
After each remediation sprint, retest corrected components to confirm fixes are accurate and have not introduced new failures. Regression is a consistent problem in CMS environments after plugin updates, theme releases, or core platform upgrades. A fix validated in one version of a component may fail silently after the next update cycle without a monitoring process in place.
Building Governance That Outlasts the Audit
Content publishing standards are as operationally important as technical remediation. The most common content-level failures, including missing alt text, incorrect heading selection, inaccessible table structures, and non-descriptive link text, are preventable with trained editorial teams and clearly documented organizational standards.
Procurement requirements should mandate WCAG 2.1 AA conformance from all third-party vendors providing embedded tools, plugin components, or content delivery services. A vendor's own accessibility statement does not transfer compliance liability away from your organization.
Regression testing should be integrated into the development release cycle, not treated as a separate audit event. Automated scanning integrated into deployment pipelines catches regressions before they reach production and reduces remediation cost significantly.
Accessibility conformance statements published on your site document your current conformance posture, known exceptions, and contact information for users encountering barriers. They are recognized as a good-faith compliance indicator in DOJ guidance and are a standard expectation in structured settlement agreements.
The Binary Works supports organizations through complete audit and remediation programs on WordPress and Drupal platforms, including content governance frameworks and editorial team training. Learn more at thebinaryworks.com.
10. Frequently Asked Questions
Q: How long does a professional website accessibility audit take?
For a mid-sized site, a complete audit combining automated scanning, structured manual testing, and assistive technology validation typically requires two to four weeks, depending on site complexity, content volume, and the number of unique template types in scope.
Q: Can internal teams conduct a credible accessibility audit?
Internal teams can run effective automated baseline scans and conduct initial keyboard navigation reviews. Comprehensive manual testing and assistive technology validation require familiarity with WCAG success criteria interpretation and how assistive technologies parse web content in practice. Most organizations combine internal scanning with specialist-led review to achieve legal defensibility.
Q: How frequently should accessibility audits be scheduled?
At minimum, annually and following any significant site change, including major platform updates, new theme deployments, or substantial content expansion. Organizations with high content publishing volumes or elevated litigation exposure should consider quarterly targeted reviews of high-traffic and transactional pages.
Q: What is the legal difference between a WCAG Level A and Level AA audit?
Level A addresses the most critical access barriers. Level AA is the compliance benchmark referenced in ADA litigation, DOJ guidance, and Title II rulemaking. Any audit conducted for compliance purposes should target Level AA conformance as its baseline. Auditing only to Level A leaves documented WCAG gaps that regulators and plaintiffs will independently identify.
Q: Does fixing automated scan failures achieve WCAG compliance?
No. Automated tools surface 25 to 40 percent of WCAG failures. An organization that remediates only automated findings has a partial remediation record and remains non-conformant on the majority of its actual failure points. Legal defensibility requires demonstrating a complete audit and remediation methodology, not only automated scan resolution.
Your Website vs ADA Compliance: Know Where to Look and How to Fix It
Get Your Free Accessibility Audit