Guide · accessibility
Automated accessibility testing: what it catches and what it misses
Automated accessibility tools are fast and repeatable, and they find real problems. They also cover only part of what WCAG asks for. This guide separates what a rules engine can decide from what needs a person, so a clean scan is not mistaken for an accessible site.
Facts checked
What automated checks do
A rules engine such as the open-source axe-core runs inside the rendered page, inspects the DOM and computed styles, and reports violations of its rules: missing form labels, insufficient colour contrast, missing accessible names and similar. Results are deterministic, so you can run them on every release.
When the engine cannot be certain, it reports the element as “incomplete” for a person to review rather than guessing. Those items are part of the result, not noise to skip.
How much is covered
The axe-core project says that, on average, it finds 57% of WCAG issues automatically. That is a project estimate, not a guarantee for your site, and the rest needs human judgement. Any tool that implies it can certify a site as accessible is claiming more than the evidence supports.
| Question | Automated? | Why |
|---|---|---|
| Is text contrast at least 4.5:1 (3:1 for large text)? | Mostly | Computed colours can be measured. Text over images and gradients is harder to judge. |
| Does every form control have a label or accessible name? | Yes | The relationship is in the DOM. |
| Does an image have alt text? | Presence only | A tool can see that alt exists, not whether it describes the image. |
| Can every control be reached and used by keyboard? | Partly | Tools find some traps; real keyboard journeys need a person or a scripted test. |
| Is the focus order logical and visible? | Partly | Order can be read; whether it makes sense depends on the task. |
| Does the page work at 320 CSS px wide without sideways scrolling? | Yes | It is a viewport measurement (WCAG 1.4.10 Reflow). |
| Is the experience usable with a screen reader? | No | It needs a person with assistive technology. |
What Sybqa runs, and what it does not claim
- axe-core runs in the page on rendering browsers, at desktop, phone and narrow widths.
- Journey steps record measured text contrast, and the contrast rule’s default threshold is WCAG’s 4.5:1. Below it is a failure; a missing target is reported as blocked, not passed.
- Deterministic checklist rules cover touch-target size (WCAG 2.5.8), persistent visible labels and error association.
A practical routine
- Run automated checks on every release and fix what they find first; they are cheap.
- Review “incomplete” and needs-review items by hand.
- Once per major change, walk the main journey by keyboard only, then with a screen reader.
- Keep the evidence: screenshots and steps to reproduce make fixes faster to verify.
To put accessibility scans alongside journeys, monitoring and pre-launch checks, see the web application testing tools and software guide.
Common questions
Is a clean automated scan enough for compliance?
No. Automated tools cover only part of WCAG, and compliance is a judgement about your site and your obligations. Use automated results as a floor.
Which standard does Sybqa measure against?
Contrast uses the WCAG 4.5:1 threshold by default, touch targets follow WCAG 2.5.8, and axe-core supplies its own rule set. It does not produce a conformance claim.
Sources
Related
Try Sybqa on your site
Paste a link, review the plan, and read the evidence report. The free plan gives 10 runs a month without AI review after you sign up.