The Engine: A Real Browser, Not a Guess
Every scan loads your page in a real, headless Chrome browser, the same rendering engine behind Chrome and Chrome DevTools, not a static parse of your HTML source. That matters because most modern sites render content with JavaScript: a static parser sees the page before your scripts run, while AccessBell sees exactly what a visitor's browser sees, including content added by React, Vue, a page builder or a third-party app.
Once the page is loaded, AccessBell runs axe-core (opens in a new tab), the open-source accessibility testing engine built by Deque Systems and used inside Chrome DevTools, Lighthouse, and most professional accessibility tools. axe-core is built specifically to avoid false positives: when it reports a failure, it is checking against an explicit, machine-testable condition in the WCAG success criteria, not a guess.
If a page cannot be reached in a full browser (for example, a target that blocks our scanner), AccessBell falls back to a direct HTML analysis so you still get a result, and the report says clearly which engine ran and what that means for coverage.
What We Check
You choose the standard: WCAG 2.2, 2.1 or 2.0 at Level AA, or a preset mapped to the ADA, Section 508 or EN 301 549. The table below is computed directly from the same rule engine your scan runs, not a marketing estimate, and updates automatically as axe-core adds rules.
| Standard | Automated rules | Success criteria tested automatically |
|---|---|---|
| WCAG 2.2 AA | 63 | 20 of 55 |
| WCAG 2.1 AA | 62 | 19 of 50 |
| WCAG 2.0 AA | 60 | 17 of 38 |
Every automated rule is mapped to the specific success criterion it tests. Browse the full list, with what each criterion requires and how to test it by hand, in the WCAG Success Criteria Library.
What Automated Testing Cannot Catch
No tool, ours included, can automatically test everything in WCAG. Roughly a third of success criteria at Level AA require human judgment: whether alt text actually describes an image's purpose, whether a focus order is logical to a real user, whether captions are accurate, or whether an error message is genuinely helpful. AccessBell lists these as items for manual review in every report, rather than silently skipping them or claiming a false pass.
This is also why AccessBell does not sell an overlay widget. A script that patches your page in the browser cannot make the manual judgment calls above, and it does not change the code a screen reader or a future audit actually reads. See our breakdown of the FTC's findings on overlay claims for why regulators have taken a skeptical view of that approach.
How We Turn a Failure Into a Fix
Every issue in a report includes the specific failing HTML, the WCAG success criterion it violates, and a corrected code example for the most common patterns, drawn from how the issue is actually fixed in real markup, not a generic description. The goal is that a developer can act on a report without first translating "color contrast" into a line of CSS to change.
How We Keep This Accurate
Every guide on this site is checked against a primary source: the W3C's WCAG specification and Understanding documents, the DOJ's or HHS's published rules, or axe-core's own rule documentation. Where a page cites a statistic, a deadline or a legal requirement, it links to that source directly so you can verify it yourself. Pages carry a review history showing when they were last checked and what changed. If you find an error, tell us and we will review it.
What This Does Not Mean
A clean AccessBell report is a strong signal, not a certification. It means the specific rules described above found no failures on the pages you scanned, at the moment you scanned them. It does not mean your site is guaranteed to meet WCAG in full, and it is not legal advice about your compliance obligations under the ADA or any other law. See our disclaimer for the full picture, and pair automated scans with the manual testing your report calls out.