Scope and Limitations

Inclusify scans pages with axe-core, the same rules engine behind Google Lighthouse and Microsoft Accessibility Insights. It runs each page in a real browser and checks it against the WCAG success criteria a machine can check.

That is a genuine part of the standard, and it is only a part. The long-standing figure across the industry, and our own experience, is that automated testing finds roughly a third of the accessibility barriers on a page. The rest are judgements: whether alternative text describes the right thing, whether a heading structure matches the content under it, whether the tab order is the order a person would expect, whether an error message actually tells somebody what to do.

The specific things a scan cannot confirm are worth naming, because they are the ones customers assume are covered: keyboard order, focus visibility, screen-reader output, whether alternative text is meaningful, and reflow at small sizes. Where a legal obligation points at EN 301 549 rather than WCAG directly, note that the standard covers considerably more than web content, including documents, hardware and support services.

This page is the list of what we do not cover. It is deliberately specific, so that our automated coverage is stated plainly rather than implied by everything we do report.

None of the following is checked by our scanner, fixed by our widget, or reflected in your score. If your site depends on any of it, that content needs to be assessed some other way.

• Documents: PDF, Word, Excel and PowerPoint files are not opened, not checked and not remediated, whether they are linked from a scanned page or hosted alongside it. This one matters more than its position in a list suggests: a linked PDF is frequently the least accessible thing a site publishes, and it is invisible to us.
• Video and audio: We do not check whether captions exist, and where a caption track is present we cannot judge whether it is accurate, complete or in sync. We do not check for transcripts or audio description, and we generate none of the three.
• Cross-origin iframes and third-party embeds: A browser will not let a script in one origin read the document inside another, which is a security boundary and not a gap we can close. So a booking widget, payment form, chat launcher, map, review carousel or embedded video player loaded from another domain is a separate document, and our scan stops at its edge. The widget cannot reach inside it either. What you see reported for a page is the page, not the third-party content sitting in it.
• Canvas and WebGL: Anything drawn to a canvas is pixels rather than elements, so a chart, map, seat picker, configurator or game rendered that way has no structure for us to inspect. A scan of such a page reports on the markup around the canvas and says nothing about what is inside it.
• CAPTCHA: We do not check, bypass, solve or replace a CAPTCHA, and our scanner is stopped by one like any other visitor. Worth flagging on its own terms: a CAPTCHA is one of the more common ways a site becomes unusable for someone, and it is entirely outside what we measure.

The widget is a set of controls a visitor can use on your site: text size, contrast, spacing, a reading mask, read-aloud, a jump list of the page’s headings and landmarks, and the rest. It is worth having. It is not remediation, and we would rather say so here than have you find out from somebody else.

• It does not modify your site’s code: No files are written, no theme is edited, no markup is rewritten at the source. The script applies changes to the page as rendered, in the browser that loaded it.
• It runs only in the visitor’s browser: Anything a visitor turns on affects that one session and nothing else. It is not visible to another visitor, to a search engine, to an auditor reading your source, or to an automated scan of your page.
• It leaves nothing behind when removed: Delete the script tag or turn off the app embed and the site is exactly as it was. There are no residual files, no database rows in your system and no theme changes to unpick.

Those three properties are the point of the design, and they are also the reason the widget cannot fix an accessibility problem. If an image has no alternative text, a form field has no label, or a heading order is wrong, that is a defect in your code, and the fix is in your code. No script running in a visitor’s browser changes what your site sends. We do not describe the widget as compliance, and a claim that an overlay makes a site compliant should be treated with suspicion wherever you meet it.

Several of our checks go beyond static rules and drive a real browser. They are useful precisely because they behave more like a person than a linter does, which is also what makes it important to be clear that they are simulations.

• The keyboard walk: Tabs through a page and records what receives focus, in what order, and whether the focus indicator is visible and unobscured. It is a keyboard simulation, not a keyboard user. It cannot tell you whether the order it found makes sense for your content, or whether a control that is reachable is understandable when you get there.
• The screen-reader transcript: Computes the accessible name and role of each element from the browser's accessibility tree and reads the page back in that order. Real screen readers are not that. JAWS, NVDA and VoiceOver differ from the tree and from each other in how they announce tables, live regions, custom controls and ARIA the specification permits but they handle their own way.
• Condition simulation: Approximates reduced motion, forced colours, narrow-width reflow and similar conditions by setting them in the browser. It shows what the page does under that setting. It does not show what somebody who relies on that setting experiences.

None of this replaces testing with real users. A meaningful share of accessibility barriers are only findable by somebody using the site with the assistive technology they use every day, at the speed and in the way they normally use it. If accessibility matters to your organisation, budget for that testing. Our results are a way to arrive at it with the mechanical problems already cleared, not a substitute for it.

It is not legal advice, and it is not a finding about any particular site. Whether a given law applies to your organisation, and what it requires of you, depends on facts about your organisation that we do not hold. Inclusify is not a law firm.

It is also not a list of everything that might be wrong with your site. It is the list of what our tools do not look at, which is a different and shorter document. For the standards and the laws themselves, see Compliance & Legal in the documentation. For a per-site statement of where your own site stands, including its known limitations, use the accessibility statement generator in your panel.

If something on this page is unclear, or you think we have understated a limitation, we would like to know. Nothing about this list is commercially convenient, and it is more useful to us accurate than short.