Under deuteranopia simulation, your form’s error and success states look identical. That’s a real failure affecting 300 million people, and standard automated audits rarely catch it. Web accessibility simulation exists to surface exactly this kind of barrier, and it does that job well.
What it can’t do is check the code underneath. Missing ARIA labels, broken heading structure, form inputs without programmatic labels: none of that surfaces under a visual filter.
This article covers what simulation genuinely reveals and what it leaves unchecked.
What web accessibility simulation can tell you
1. Whether your design relies too heavily on color
Color blindness affects roughly 300 million people worldwide. Deuteranopia and protanopia, the two most common forms, make red-green distinction difficult or impossible. Tritanopia affects blue-yellow perception. Achromatopsia removes color perception entirely. For each of these, the problem is whether your UI still communicates meaning when the color signal is gone.
That’s where automated tools have a gap.
They reliably catch contrast failures (WCAG 1.4.3), low-contrast text appears on 83.9% of homepages, per the WebAIM Million 2026 report. But Use of Color violations (WCAG 1.4.1) are harder to detect automatically.
When a form validation state only changes in color, or a chart distinguishes data series by hue alone, most tools won’t flag it. Some advanced rulesets can identify adjacent DOM states that lack complementary text or semantic changes, but standard tools don’t evaluate whether a color change carries meaning on its own. Simulation makes this visible.
Common failures that surface under color blindness simulation:
- Form validation states that turn red for errors and green for success become indistinguishable under deuteranopia without an icon and text label
- Charts and graphs that differentiate data series by color alone lose all meaning. Add direct labels, patterns, or texture.
- Links styled only with color often become indistinguishable from surrounding text in several simulation modes. The text is still there; what’s lost is the visual distinction. An underline fixes this.
- Status badges that rely solely on hue become unreadable once the color signal is gone
Also read: Colour Contrast and Accessibility – A Complete Guide
2. Whether your typography creates reading barriers
Dyslexia affects an estimated 10 to 15 percent of the population. It’s a language processing difference, and the barriers it creates are largely cognitive and layout-driven; dense line spacing, wide text columns, justified alignment, and small font sizes all add friction that compounds over a long read.
Think of the dyslexia simulation as a nudge to investigate readability issues, not a window into how dyslexia feels for any individual. It’s a useful prompt: if a block of text feels hard to parse under the filter, that’s a signal to look more closely at the layout. The simulation works best as a trigger for the typography review below rather than a pass/fail result on its own.
Typography issues to check:
- Line length: Text blocks wider than 70 to 80 characters are harder to track. A max-width on text containers fixes this in one line of CSS.
- Line height: WCAG 1.4.12 requires content to remain functional when users override line height to 1.5x or above. It’s a requirement to support that override, not a prescription to set 1.5 by default. That said, building base styles close to that value reduces the chance of content breaking when users apply it.
- Text justification: Left-align body copy. Full justification creates uneven word gaps that break tracking.
- Placeholder text as instructions: Move form instructions above the input. They disappear the moment a user starts typing.
3. Whether low vision users can complete core tasks
The WHO estimates 2.2 billion people globally live with some form of visual impairment. Many of them don’t use screen readers. They rely on magnification and the visual design decisions your team has already made.
Using native browser development tools (such as Chromium’s rendering panel), you can simulate how interfaces behave under various vision impairments.
If you need more simulations, prefer tools like Accessibility Checker extension by WebYes, which covers seven impaired vision simulations, each targeting a different condition:
- Cataracts: Cloudy, hazy vision from clouding in the eye’s lens; simulated at adjustable severity levels
- Glare sensitivity: How bright light sources and high-contrast edges affect readability
- Yellowing: Color perception changes caused by lens yellowing, common in aging eyes
- Loss of peripheral vision: Tunnel vision effect, as seen in glaucoma
- Loss of central vision: Blind spot at the center of the visual field, as seen in macular degeneration
- Loss of contrast: Overall reduction in contrast sensitivity, separate from the WCAG contrast ratio metric
- Double vision: Overlapping images that affect reading and spatial accuracy
Looking at your page tells you very little. Interact with it under each condition. Try to complete a specific task, something like submitting a form or finding a product, and note what breaks.
Issues that surface when you actually use the page:
- Font size: Body text under 16px becomes significantly harder to read under cataracts and loss of contrast. Increase base sizes and verify the page holds up at 200% browser zoom.
- Interactive target size: WCAG 2.5.8 (Level AA) requires a minimum target size of 24×24 CSS pixels. Small targets become impossible to hit accurately under loss of peripheral or central vision. For reference, 2.5.5 sets a 44x44px target but sits at Level AAA.
- Contrast under dimming: Contrast that passes WCAG AA at normal brightness often fails under the loss of contrast simulation. Check every text color against its background, including placeholder text.
- Focus indicators: Thin 1px outlines disappear entirely under multiple impaired vision modes, effectively invisible for anyone relying on magnification to get around the page.
4. Whether your fixes are working
Simulation doubles as a verification tool. Once you’ve added an icon and text label to a color-only form validation state, running the simulation again confirms the state is now legible without the color signal. That loop runs in under two minutes and doesn’t require recruiting users or setting up a formal test.
What web accessibility simulation can’t tell you
1. Whether your site is technically compliant
Simulation evaluates the visual experience. The code underneath can still be broken. A site can look fine under every simulation filter and still fail WCAG, with missing aria-label attributes, incorrect heading order, or form inputs without programmatic labels.
According to the WebAIM Million 2026 report, 95.9% of the top 1 million homepages have detectable WCAG failures, averaging 56.1 errors per page. Simulation doesn’t catch the majority of those. Missing form labels and empty buttons won’t surface in any simulation pass.
Both matter. The simulation shows you where the experience breaks down. A WCAG audit catches the code-level failures that don’t show up visually at all.
In the Accessibility Checker by WebYes, both live in the same extension. When the dyslexia simulation flags that your line spacing looks wrong, you can run a WCAG check immediately to confirm whether it fails the 1.4.12 text spacing criterion, without switching tools.
Also read: How accessibility testing actually works in Chrome
2. Whether the experience is accurate to any individual user
Color blindness simulations use established color transformation matrices, but two people with deuteranopia don’t see the world identically. Dyslexia simulation approximates general reading friction; it can’t account for how any individual processes text. Low vision is an especially broad category, with enormous variation in how people experience it.
Treat simulation findings as evidence that a category of problem exists, worth investigating further with real users.
3. What your users are actually doing
Simulation shows you what a page looks like under a condition. It doesn’t tell you where users get confused or whether they abandon a task entirely.
That’s usability testing’s job. Watching a person with low vision try to complete a purchase, seeing where they zoom in and where they lose their place, gives you something simulation can’t produce. Simulation surfaces a problem worth investigating. User testing is where you find out what it’s costing you.
4. The full disability spectrum
The conditions simulation covers are a fraction of the disability spectrum. Anyone relying on assistive technology or affected by motor and hearing disabilities won’t be represented in a simulation pass. A site that clears your simulation checklist can still be entirely unusable for a significant portion of disabled users.
How to use accessibility simulation effectively
Research consistently shows fixing accessibility issues before development is significantly cheaper than post-launch remediation; some estimates put the gap at an order of magnitude or more. The earlier you simulate the process, the less it costs to act on what you find.
A practical workflow:
- Apply the simulation and actually use the page. Click through it, scroll, read the body copy. Observation alone misses interaction-level failures.
- Note what breaks. Take screenshots and bring them into your next design or development review.
- A WCAG audit should be the next step. The simulation shows you something broke visually. The audit identifies the technical failure and tells you what to fix.
A good starting point is to run simulations at the same cadence you audit for WCAG compliance, or more often if capacity allows. It also fits naturally into any pre-launch checklist.
Wrapping up
Web accessibility simulation requires no account and takes under two minutes on any live page. The findings are visual enough that a designer and developer can look at the same screenshot and agree on what’s broken, without needing to parse an audit report.
The right expectation matters here. Simulation shows you a specific, real category of failures on your actual product. Running it once isn’t a substitute for testing with disabled users, and it won’t tell you everything.
What it does tell you is: here’s what some of your users are dealing with, right now, on your actual product.
AUTHOR
Anjaly Rose is a content writer with over four years of experience working across B2B, SaaS, and e-commerce. She holds a bachelor’s degree in English Literature and is interested in marketing and psychology. Outside of work, she enjoys character-driven films and literary fiction.
Melwyn Joseph 
