Automated Website Accessibility Audit Report
Scan your webpage HTML for common WCAG 2.1 bottlenecks: image alt coverage, form input descriptions, document language tags, and ARIA landmarks.
Automated testing covers approximately 30% to 40% of WCAG success criteria. Passing automated checks does not certify complete WCAG compliance. This tool provides an informational technical audit and does not constitute legal advice.
Understanding Automated Accessibility Auditing
📌 On this page
1. How this scan works
The server fetches your page's raw HTML with an 8-second timeout — the same document a search crawler or a browser's initial parse would see — and inspects it with regular-expression pattern matching. There is no headless browser involved, so JavaScript-injected content, computed CSS (like color contrast), and dynamic ARIA state changes are invisible to this scan. It checks five specific, verifiable patterns in the raw markup and reports pass/warn/fail for each.
2. The five checks explained
Document Language checks for a lang attribute on the <html> tag, which screen readers use to select the correct pronunciation engine. Keyboard Navigation looks for a skip link, letting keyboard users jump past repeated navigation. ARIA Landmarks checks for semantic HTML5 elements (<main>, <nav>, <header>) or explicit ARIA roles that let screen reader users jump between page regions. Image Alt Text measures what percentage of <img> tags carry an alt attribute. Form Inputs estimates whether interactive fields have an accessible name via aria-label, aria-labelledby, or an id (which likely pairs with a <label for>).
3. What automated testing can and can't catch
Industry research consistently finds automated tools catch somewhere between 30-40% of WCAG success criteria — the ones that map cleanly onto a static or computed markup pattern (missing alt text, missing labels, missing lang attributes, insufficient color contrast when rendered). The remaining 60-70% require human judgment: is the alt text actually descriptive and accurate (not just present), does the tab order match the visual reading order, can every custom widget be operated with a keyboard alone, is the reading experience coherent when navigated by heading structure alone? No automated tool, including this one, can answer those questions.
4. WCAG conformance levels: A, AA, AAA
WCAG success criteria are organized into three conformance levels of increasing strictness: A (minimum, addresses the most severe barriers), AA (the level referenced by most legal requirements and accessibility policies worldwide, including ADA-related litigation in the US and the EN 301 549 standard in the EU), and AAA (the highest level, often impractical to achieve for an entire site). Most organizations target WCAG 2.1 Level AA as their compliance baseline — the checks in this scanner map to a mix of Level A and AA success criteria.
5. Accessibility and legal risk in plain terms
In the United States, website accessibility lawsuits under the ADA have increased substantially over the past decade, and courts have generally applied WCAG 2.1 AA as the de facto technical standard even though the ADA itself doesn't name a specific standard for websites. This report is a technical diagnostic, not a legal risk assessment — organizations with meaningful legal exposure (public-facing businesses, especially in retail, hospitality, finance, and government contracting) should consult an accessibility-focused legal counsel or a certified accessibility auditor (e.g., IAAP CPACC/WAS certified) for a formal compliance opinion.
6. Building a complete accessibility testing process
A practical, layered testing process looks like this: run this scan (or a similar tool) early and often during development to catch the cheap, structural issues immediately; add a browser-based automated tool like axe DevTools to your CI pipeline or QA checklist to catch rendering-dependent issues like contrast; and periodically run a manual test pass — keyboard-only navigation, a real screen reader, and ideally feedback from actual assistive-technology users — before major releases. No single layer is sufficient alone, but together they catch the large majority of real-world barriers.
Frequently Asked Questions
What portion of WCAG guidelines can automated tools test?
Automated tools can only test roughly 30% to 40% of WCAG success criteria (such as missing alt tags, lang attributes, and form labels). Human manual testing with screen readers and keyboard navigation is required for full compliance.
Does achieving a 100% automated score mean my website is legally ADA compliant?
No. This report is an informational diagnostic audit and does not constitute a legal opinion or formal compliance guarantee.
How do skip navigation links assist screen reader users?
A skip link allows keyboard and screen reader users to bypass repetitive header navigation menus and jump directly to the primary page content.
What exactly does the "Form Inputs" check look for, and what does it miss?
This check flags an input as covered if it has an aria-label, aria-labelledby, or even just an id attribute, since an id often pairs with a matching <label for="..."> element elsewhere in the HTML. It cannot verify that a label actually exists and correctly references that id — that requires cross-referencing the full DOM structure, which this lightweight HTML-pattern scan does not do. Treat a "pass" here as "likely labeled," not "confirmed labeled," and spot-check your forms with a screen reader.
What common accessibility issues does this scan NOT catch?
Because this is a static HTML pattern scan (no browser rendering, no JavaScript execution), it cannot detect color contrast failures, keyboard focus traps, dynamic content that doesn't announce itself to screen readers, video/audio without captions, illogical reading order, or interactive elements that are visually present but not truly keyboard-operable. These require either a browser-based automated tool (like axe DevTools or Lighthouse's accessibility audit) or manual testing.
What's a reasonable next step after fixing everything this tool flags?
Run a browser-based automated scanner like axe DevTools or WAVE for a deeper automated pass (they execute JavaScript and check computed styles, catching contrast and dynamic-content issues this HTML-only scan can't see), then do a manual pass: navigate your site using only a keyboard (Tab, Shift+Tab, Enter, Space) and verify every interactive element is reachable and operable, and ideally test with a real screen reader like NVDA (free, Windows) or VoiceOver (built into macOS/iOS).