Your site scores 100/100 on the axe-core audit. And yet, since the last CSS update, your buttons' contrast has dropped below the legal threshold and the focus indicator has vanished — invisible to the code analyzer, very real for the user and the regulator alike. That's the blind spot of traditional accessibility tools: they read the code, not the rendering.
And the stakes aren't merely cosmetic. Web accessibility obligations vary by jurisdiction: the European Union mandates level AA through the European Accessibility Act, the United States requires Section 508 compliance under the ADA, Canada aligns the ACA with WCAG 2.1 AA, and the United Kingdom applies its own rules through the Equality Act. This guide compares the requirements by region, details the steps of a complete WCAG test, and explains how automated visual testing complements static analysis tools to cover the full set of criteria.
Your code audit says "compliant," but the screen tells a different story? Delta-QA spots the contrast, focus, and layout gaps that static analyzers miss — on your own machine, no sign-up. Try Delta-QA free →
What WCAG requires visually
The WCAG (Web Content Accessibility Guidelines) version 2.2 contains 86 success criteria spread across three conformance levels: A, AA, and AAA. Among these criteria, a significant proportion directly concerns the visual appearance of interfaces.
Let's look at the most important ones.
Color contrast (criterion 1.4.3 for level AA, 1.4.6 for AAA) requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text. This criterion is purely visual: it is verified by comparing the colors of text and its background.
Text size (criterion 1.4.4) requires that content can be enlarged up to 200% without loss of information or functionality. This means that at 200% zoom, text must not overflow its containers, elements must not overlap, and information must remain readable. All of this is visually verifiable.
Focus indicator (criterion 2.4.7 for AA, strengthened by 2.4.11 and 2.4.12 in WCAG 2.2) requires that every interactive element displays a visible indicator when it receives keyboard focus. This indicator must have sufficient contrast and a minimum surface area. Once again, this is a visual criterion.
Text spacing (criterion 1.4.12) requires that content remains functional when the user modifies line height to 1.5 times the font size, paragraph spacing to 2 times, letter spacing to 0.12 times, and word spacing to 0.16 times. If these adjustments break the layout, it is an accessibility violation detectable visually.
Content reflow (criterion 1.4.10, also called "reflow") requires that content displays without horizontal scrolling at a width of 320 CSS pixels. This is exactly what responsive testing verifies.
The conclusion is clear: a significant part of WCAG compliance relies on measurable visual properties.
WCAG testing requirements by region
Legal obligations for digital accessibility vary by jurisdiction. The table below compares the requirements across four major regions.
| Region | Required Standard | Mandatory WCAG Level | Deadline / Year | Legislation | Recommended Tool(s) |
|---|---|---|---|---|---|
| EU / EAA | EN 301 549 (aligned with WCAG 2.1) | AA | June 2025 (enforcement) | European Accessibility Act (EAA) — Directive 2019/882 | axe-core, WAVE, Lighthouse |
| US / ADA + Section 508 | Section 508 (aligned with WCAG 2.0) | AA | Section 508: January 2018 (update); ADA: ongoing case law | ADA.gov — Section 508 (29 U.S.C. § 794d) | axe-core, ANDI, WAVE |
| Canada / ACA | ACA (aligned with WCAG 2.1) | AA | June 2024 (phase 1); June 2025 (phase 2) | Accessible Canada Act (ACA) | axe-core, Accessibility Insights |
| UK / EQS | Public Sector Bodies Accessibility Regulations 2018 | AA | September 2020 (public sector) | Equality Act 2010 — Accessibility Regulations | axe-core, WAVE, Pa11y |
Key takeaways from the table:
- All four jurisdictions require at minimum WCAG AA. None mandates AAA, but reaching it reduces legal risk.
- The European Union has the most recent and stringent deadline with the EAA, which also covers the private sector.
- The United States remains on WCAG 2.0 via Section 508, but courts increasingly apply WCAG 2.1 AA as the reference under the ADA.
- Canada and the United Kingdom have aligned with WCAG 2.1 AA, with phased enforcement timelines.
- axe-core, developed by Deque Systems, is the most cited tool across all jurisdictions — it integrates with testing frameworks and CI/CD.
How to conduct a complete WCAG test: The steps
A complete WCAG test combines automated analysis, visual verification, and manual audit. Follow these steps, in order.
- Define the test scope. Identify the pages and components to test, the applicable jurisdiction(s) (see table above), and the target conformance level (AA in virtually all cases).
- Run an automated analysis with axe-core. Execute axe-core on each page in scope. This tool detects approximately 30 to 50% of WCAG violations — those verifiable through DOM analysis (missing text alternatives, incorrect ARIA roles, heading structure, form attributes).
- Run a Lighthouse audit. Complement the axe-core analysis with Google Lighthouse, which evaluates the "Accessibility" category out of 100 and flags common issues with fix suggestions.
- Verify visual criteria through screenshot testing. Capture your pages under accessibility conditions: 200% zoom, 320px width, WCAG spacing styles injected (criterion 1.4.12), forced keyboard focus. Compare results against a compliant baseline to detect regressions. Visual regression testing is the most reliable method for this step.
- Manually test keyboard navigation. Navigate each page using only the keyboard (Tab, Shift+Tab, Enter, Space, arrow keys). Verify that the tab order is logical, that every interactive element receives visible focus, and that no keyboard traps exist.
- Verify compatibility with assistive technologies. Test your pages with a screen reader (NVDA on Windows, VoiceOver on macOS/iOS, TalkBack on Android). Check that content is correctly announced, that region landmarks are present, and that forms are usable.
- Test across multiple browsers and devices. Accessibility issues vary from one rendering engine to another. A compliant contrast on Chrome may not be compliant on Safari. Cross-browser visual testing captures these discrepancies.
- Document results and corrections. For each detected violation, reference the relevant WCAG criterion, the applicable jurisdiction, the severity, and the correction applied. This documentation serves as proof of compliance in case of an inspection.
- Integrate tests into your CI/CD pipeline. Automate steps 2, 3, and 4 to run on every pull request. Any regression is blocked before reaching production. Our CI/CD pipeline integration guide details the setup.
- Schedule recurring audits. Even with full automation, a quarterly or semi-annual manual audit by a WCAG expert remains recommended to cover non-automatable criteria.
Why traditional accessibility tools are not enough
Accessibility audit tools like axe-core or Lighthouse are indispensable. They analyze the DOM, check ARIA attributes, detect missing tags, and flag structural violations. Nobody questions that.
But these tools have a fundamental limitation: they analyze code, not rendering. They verify what HTML and CSS declare, not what the user actually sees.
A concrete example. Imagine a button with white text on a blue background, with a compliant contrast ratio of 5.2:1. During a CSS update, a developer changes the button's background color to a lighter shade without touching the text. The ratio drops to 2.8:1. axe-core can detect this in some cases, but only if the stylesheet is correctly interpreted by the analysis engine. Visual testing, however, catches this regression immediately because it compares the actual rendering of the button before and after the change.
Another common case: the focus indicator is defined in CSS, but a framework update removes or overrides the outline style. Functionally, the button remains clickable. Structurally, the HTML is intact. But visually, the focus has disappeared. No DOM analysis tool reliably flags this issue. Visual testing detects the rendering difference.
These tools also fail to detect zoom-related issues. When a user enlarges text to 200%, overflows, overlaps, and truncated text are purely visual problems. They don't appear in static code analysis.
Traditional accessibility tools are necessary but insufficient. They cover structural criteria (text alternatives, heading structure, ARIA roles), but they leave a blind spot on everything related to visual rendering — the very gap visual regression testing was designed to fill.
Visual testing as a safety net for accessibility
Automated visual testing involves capturing screenshots of your pages and components, then comparing them to a reference (baseline) to detect any unintended visual change. Applied to accessibility, this mechanism becomes a formidable safety net.
Here's why.
It detects regressions, not just violations. An accessibility audit tells you if your site is compliant at a given point in time. Visual testing alerts you as soon as a code change degrades visual accessibility. It's the difference between a diagnosis and an alarm system.
It works on the actual rendering. Visual testing captures what the browser actually displays, after applying all stylesheets, JavaScript scripts, and layout calculations. It doesn't interpret CSS — it observes the result.
It covers multi-browser and multi-resolution cases. Visual accessibility issues vary across browsers and screen sizes. A compliant contrast on Chrome may not be compliant on Safari if fonts are rendered differently. Cross-browser visual testing captures these differences.
It integrates into CI/CD. By running visual tests on every pull request, you detect accessibility regressions before they reach production. This is prevention, not correction. Our CI/CD pipeline integration guide walks through the setup.
It doesn't require accessibility expertise to set up. Any team member can set up a visual test that captures pages at different zoom levels or with forced focus styles. The comparison is automatic.
Accessibility rules differ by region. Your testing shouldn't break the bank. Catch visual regressions that hide compliance issues with Delta-QA's free Desktop app, no-code and running entirely on your own machine. Try Delta-QA free →
WCAG criteria that visual testing detects natively
Let's go criterion by criterion through the WCAG aspects that visual testing covers effectively.
Criteria 1.4.3 and 1.4.6 — Contrast. By combining visual testing with color blindness simulation filters or by extracting colors from screenshots, you can verify that contrast remains compliant after each change. A palette change that degrades contrast will be immediately visible in the screenshot comparison.
Criterion 1.4.4 — Text resize. Capture your pages at 200% zoom. Any regression (truncated text, overlapping elements, overflowing containers) will be detected by visual comparison.
Criterion 1.4.10 — Reflow. Capture your pages at a width of 320 CSS pixels. Responsive visual testing verifies that content adapts correctly without horizontal scrolling.
Criterion 1.4.12 — Text spacing. Inject the spacing styles required by the criterion (line height 1.5, paragraph spacing 2x, letters 0.12em, words 0.16em) and capture the result. Compare with the baseline to detect elements that break under these constraints.
Criteria 2.4.7, 2.4.11, 2.4.12 — Visible focus. Force keyboard focus on each interactive element and capture the result. Visual testing detects the disappearance or degradation of the focus indicator.
Criterion 1.4.11 — Non-text contrast. Icons, form field borders, status indicators — all of these elements must have a contrast ratio of at least 3:1. Visual testing monitors them naturally.
How to set up visual accessibility monitoring
The practical implementation relies on a few simple principles.
Create baselines under accessibility conditions. Don't just capture your pages in their default state. Create additional baselines: at 200% zoom, at 320-pixel width, with WCAG spacing styles injected, and with focus forced on interactive elements.
Integrate these tests into your CI/CD pipeline. Every pull request should trigger a visual comparison across all these conditions. If a CSS change degrades visual accessibility, the test blocks the merge.
Use adapted tolerance thresholds. For accessibility tests, reduce the acceptable difference threshold. A 2-pixel change on a focus indicator can make it non-compliant. The tolerance must be stricter than for a general visual test. Our guide on reducing false positives in visual testing explains how to fine-tune thresholds without sacrificing detection accuracy.
Document your accessibility baselines. Each baseline should be associated with the WCAG criterion it verifies. This facilitates auditing and traceability in case of inspection.
Combine with static analysis tools. Visual testing doesn't replace axe-core or Lighthouse. It complements them. Use analysis tools for structural criteria (text alternatives, heading structure, ARIA), and visual testing for rendering criteria. Together, they cover virtually all of WCAG. If you're evaluating which tool fits your accessibility workflow, our visual testing buying guide compares the key options.
A tool like Delta-QA, which lets you configure visual tests without writing code, makes this approach accessible to the entire team, including accessibility managers who are not developers. Our no-code visual testing guide explains how no-code tools democratize this practice.
Visual accessibility is not a luxury — it's an obligation
Since June 2025, the European Accessibility Act (EAA) requires companies in the European Union to make their digital products and services accessible. In the United States, the ADA and Section 508 impose similar requirements on public-facing digital services. In Canada, the Accessible Canada Act is being progressively enforced. In the United Kingdom, the Public Sector Bodies Accessibility Regulations 2018 have been in force since 2020.
Financial penalties exist and are increasing. But beyond legal risk, accessibility is a competitive advantage. According to the World Health Organization, more than one billion people worldwide live with some form of disability. The cost of visual bugs in this context is not just financial — it's exclusionary. Ignoring accessibility means ignoring a considerable market.
Visual accessibility is the most easily automatable part of this obligation. You don't need a WCAG expert to capture screenshots under different conditions and compare results. A no-code visual testing approach makes this accessible to every team member. You need a well-configured visual testing tool.
FAQ
How do I test WCAG compliance by region?
Start by identifying the applicable jurisdiction(s) for your product (EU, US, Canada, UK, or other). Refer to the comparison table above for the required standard and level. Run an automated test with axe-core for structural violations, complement with automated visual testing (captures at 200% zoom, 320px width, forced focus) for rendering criteria, and finish with a manual audit using keyboard and screen reader. Document each result with the jurisdictional reference.
Is WCAG testing mandatory in the EU?
Yes. The European Accessibility Act (Directive 2019/882), in force since June 2025, requires compliance with standard EN 301 549, itself aligned with WCAG 2.1 level AA. Non-compliance exposes companies to national sanctions varying by Member State. The scope covers digital products and services for consumers: e-commerce, banking services, transport, telecommunications, media.
What WCAG level is required for legal compliance?
All four major jurisdictions (EU, US, Canada, UK) require level AA. None legally mandates level AAA, although some AAA criteria (notably enhanced contrast at 7:1) are recommended to reduce litigation risk. In practice, targeting WCAG 2.1 AA covers the obligations of all regions listed in this guide.
What is the European Accessibility Act deadline?
The EAA was adopted in 2019 (Directive 2019/882) and entered into force on June 28, 2025. Companies were required to be compliant by that date. Member States were required to transpose the directive into national law — some have been delayed, but the obligation applies regardless of local transposition. Micro-enterprises (fewer than 10 employees and less than 2 million euros in revenue) benefit from exemptions.
How accurate are automated WCAG test tools?
Automated tools like axe-core detect between 30 and 50% of WCAG violations, according to studies by Deque Systems and the W3C WAI. They effectively cover structural criteria (text alternatives, ARIA roles, heading structure) but leave a blind spot on visual rendering criteria and actual user experience. This is why a complete test combines automation, visual testing, and manual audit.
Does visual testing replace a full WCAG accessibility audit?
No. Visual testing covers the visual criteria of WCAG (contrast, focus, spacing, zoom, reflow), but not structural criteria like text alternatives, keyboard navigation, or ARIA roles. It complements an audit — it doesn't replace one. Roughly 30 to 40% of WCAG 2.2 criteria have a direct visual component.
Which WCAG conformance levels does visual testing help verify?
Visual testing is relevant for all three levels: A, AA, and AAA. Level AA, which is most commonly required by regulations, contains several major visual criteria (contrast 1.4.3, visible focus 2.4.7, reflow 1.4.10, spacing 1.4.12). Level AAA strengthens contrast requirements (1.4.6 with a 7:1 ratio) and adds additional criteria, all visually verifiable.
How to test visual accessibility without technical skills?
With a no-code tool like Delta-QA, you configure your pages to test, define the conditions (screen size, zoom, browser), and the tool automatically captures and compares screenshots. No code required. The interface shows you visual differences, and you decide whether they are acceptable or not.
How often should visual accessibility be checked?
With every front-end code change. CI/CD integration is the best approach: each pull request automatically triggers tests. If you can't automate at this level, a weekly test is an acceptable minimum to detect regressions before they accumulate.
Does visual testing detect accessibility issues on mobile?
Yes, provided you configure tests at common mobile resolutions (360px, 375px, 414px width). Responsive visual testing captures the actual rendering at each resolution and detects reflow issues, truncated text, elements too small for touch activation, and degraded contrast from mobile rendering.
Does the European Accessibility Act apply to my business?
If you sell digital products or services to consumers in the European Union, yes. The EAA has applied since June 2025 to e-commerce sites, banking services, media, transport, and telecommunications, among others. Micro-enterprises with fewer than 10 employees and less than 2 million euros in revenue benefit from exemptions, but others must comply.
- Visual testing for Product Managers: a complete guide
- Visual Testing for Design Systems: Components and Pages
- Cypress Visual Testing: The Complete Guide to Adding Visual Testing to Cypress
- Visual Testing for Ruby on Rails: Why View Specs Are Not Enough and How Visual Testing Fills the Gap
Conclusion
An effective WCAG test by region requires knowing the legal obligations of each jurisdiction, combining automated analysis with visual testing, and integrating these checks into the development cycle. The four major regions (EU, US, Canada, UK) converge toward WCAG AA, but the standards, deadlines, and scopes differ. Automated visual testing fills the blind spot of static analysis tools by verifying actual rendering — what the user sees, not what the code declares.
Rather than treating accessibility as a one-time annual audit, integrate visual testing into your pipeline to make it continuous monitoring. It's more efficient, more reliable, and infinitely less expensive than late correction.
Ready to turn your WCAG compliance into continuous monitoring? Capture a first accessible baseline and let Delta-QA block every visual regression before production — free and no sign-up. Try Delta-QA free →