WCAG Compliance Quick Checker
Run an automated diagnostic check across WCAG Perceivable, Operable, Understandable, and Robust success criteria for any live URL or HTML code.
Technical Deep-Dive: WCAG's Four Principles in Practice
📌 On this page
1. POUR: the organizing framework behind WCAG
Every WCAG success criterion falls under one of four principles, commonly abbreviated POUR: Perceivable (can users perceive the content through at least one sense — sight, hearing, or touch via assistive tech), Operable (can users operate the interface regardless of input method — keyboard, mouse, voice, switch device), Understandable (is the content and interface behavior predictable and comprehensible), and Robust (does the content work reliably across current and future user agents, including assistive technologies). This framework is why WCAG audits are organized by these four categories rather than a flat checklist — a failure in any one principle can make content effectively inaccessible even if the other three are perfect.
2. What automated testing genuinely covers
Automated accessibility tools excel at structural and presence checks: does an image have an alt attribute, does a form input have an associated label, is there a lang attribute, does a heading hierarchy skip levels, does color contrast meet a numeric ratio threshold. These are objectively verifiable from markup alone. What automated tools cannot verify is meaning and intent: whether alt text actually describes the image content accurately, whether a heading hierarchy reflects genuine content structure versus arbitrary visual styling, whether a custom JavaScript widget is genuinely operable via keyboard (as opposed to merely having the right ARIA attributes present), or whether the overall page makes logical sense to someone using a screen reader.
3. The 30-40% figure, explained
This commonly cited industry figure (also referenced by accessibility organizations like Deque and WebAIM) reflects the proportion of WCAG success criteria that can be reliably, objectively verified by software without human judgment. The remaining 60-70% require a human evaluator to make a judgment call — is this alt text accurate, is this error message actually helpful, does this custom dropdown behave sensibly with a screen reader. This is not a limitation specific to this tool; it applies to every automated accessibility scanner, including industry-standard tools like axe-core and Lighthouse's accessibility audit, which is why professional accessibility audits always combine automated scanning with manual expert review and testing with real assistive technology.
4. Level A vs AA vs AAA: what actually changes
Level A represents the absolute floor — criteria so fundamental that failing them makes content completely unusable for some users (no alt text at all, a mouse-only interface with zero keyboard support). Level AA adds broader, more nuanced requirements like the 4.5:1 minimum color contrast ratio for normal text, resizable text up to 200% without loss of functionality, and consistent navigation across pages — this is the tier virtually all legal and regulatory frameworks target. Level AAA is the strictest tier, including requirements like 7:1 contrast and sign language interpretation for video content, but WCAG itself notes AAA is not recommended as a general policy requirement for entire sites since some AAA criteria cannot be satisfied for certain types of content regardless of effort.
5. Legal frameworks that reference WCAG
In the United States, ADA Title III litigation has increasingly used WCAG 2.1/2.2 Level AA as the de facto technical benchmark courts and settlements reference, even though the ADA statute itself does not name WCAG explicitly. Section 508 (covering US federal agencies) formally incorporates WCAG 2.0 Level AA as its technical standard. The European Accessibility Act references EN 301 549, which itself incorporates WCAG. This convergence around WCAG 2.1/2.2 AA as the practical global benchmark is why this tool (and most accessibility guidance generally) targets that specific level rather than A or AAA.
6. Building a complete accessibility testing program
A mature testing approach layers three tiers: automated scanning (fast, cheap, catches structural regressions continuously — tools like this one, axe-core, or Lighthouse), manual expert review (a trained auditor walks through the site checking judgment-dependent criteria against the WCAG checklist), and real assistive-technology testing (actually navigating the site with a screen reader, keyboard-only, and at high zoom levels, ideally including testing by people who use these technologies daily). Automated scanning alone, however thorough, only ever closes the first third of this picture — treat a clean automated report as a solid starting point, never a finish line.
Frequently Asked Questions
Can automated tools guarantee 100% WCAG compliance?
No. Automated testing tools can only test roughly 30% to 40% of WCAG success criteria. Critical accessibility requirements such as meaningful reading order, descriptive accuracy of alt text, logical focus management, and keyboard operability of custom widgets require manual expert review.
What are the 4 WCAG Principles (POUR)?
1. Perceivable: Information and UI components must be presentable to users in ways they can perceive. 2. Operable: UI components and navigation must be operable (e.g. keyboard accessible). 3. Understandable: Information and operation of UI must be understandable. 4. Robust: Content must be robust enough to be interpreted reliably by diverse user agents, including assistive technologies.
What is the difference between WCAG Level A and Level AA?
Level A comprises fundamental baseline accessibility criteria without which certain users cannot access content at all. Level AA includes broader requirements (such as 4.5:1 color contrast and responsive reflow) and is the legally recognized standard for ADA Title III and European accessibility laws.
Does this tool enforce SSRF security checks?
Yes. All live audits enforce strict SSRF safeguards, blocking requests to private networks, loopbacks, and cloud metadata IPs.
Which specific 8 checks does this automated scan actually run?
Missing image alt attributes (1.1.1), presence of a primary H1 heading (1.3.1), a working skip-to-content link (2.4.1), a non-empty page <title> tag (2.4.2), empty hyperlinks with no accessible text (2.4.4), an HTML lang attribute (3.1.1), unlabelled form inputs (3.3.2), and invalid/deprecated ARIA role values (4.1.2). Each maps to a specific WCAG success criterion and is checked via pattern matching against the fetched or pasted HTML — no rendering or JavaScript execution occurs.
Why might a page pass all 8 automated checks but still fail a real accessibility audit?
Because these checks can only verify that certain HTML attributes and elements exist, not whether they are used correctly or meaningfully. A page can have alt text on every image while half of it says "image123.jpg" or "photo" (technically present, functionally useless), have a skip link that targets a broken anchor, or have form labels that are technically associated but describe the wrong thing. Automated tools are excellent at catching missing attributes; they cannot judge the quality, accuracy, or contextual appropriateness of the content in those attributes — that gap is exactly what the 30-40% automated coverage figure refers to.