a11y-check.eu Accessibility Checker: False Positives Checked
What happened
On 25 October 2026 we ran a11y-check.eu, a free accessibility checker built on the open-source axe-core engine, on the aiwebpageseo.com home page. Its result: 0 violations, 1 item that needs manual review, and 46 rules passed.
On the same day our own Accessibility Audit scored the same page 100/100: 25 checks passed, 0 errors and 0 warnings, against WCAG 2.2.
We have tested several free checkers this month, and most reported failures that were not real. So we checked every line of this report against the live page, looking for false positives. We found none. This post explains why the two results agree, and what each tool covers that the other does not.
The short version
- Violations: 0. Our audit also found 0, and it runs axe-core rules as one of its checks.
- Needs manual review: 1 rule, 21 elements. These are text elements whose background colour axe could not work out, because they sit over a background gradient, plus the cookie banner text, which partly overlaps another element. Our audit flagged the same text: 20 elements over an image, gradient or unsupported colour, left for a person to check by eye.
- False positives: none. a11y-check.eu did not claim a failure it could not prove. Where it could not decide, it said so.
- What our audit adds: tests in a real browser that axe does not run, such as keyboard focus, the skip link, reflow at phone width, zoom, text spacing and orientation.
Checking the one review item
What the report said. Under "Needs Manual Review", the rule "Ensure the contrast between foreground and background colors meets WCAG 2 AA minimum contrast ratio thresholds", marked serious, on 21 elements. For 20 of them the reason was "Element's background color could not be determined due to a background gradient". They include the top menu links, the main heading, the opening paragraph and the section headings. For the cookie banner text the reason was that it "partially overlaps other elements".
Why that is not a false positive. axe measures contrast by comparing the text colour with one background colour. A gradient has many colours, so there is no single ratio to measure. axe does not guess: it puts the element in its "incomplete" list for a person to check. That is the correct behaviour, and the report labels it as manual review, not as a failure.
What our audit said about the same text. Our audit measures the rendered colour of every piece of text in Chrome. It measured 271 text elements and found none below the AA level. It listed 20 text elements over an image, gradient or unsupported colour as "Requires verification: check them by eye". Those are the same elements, give or take the cookie banner, which our audit measured.
What the rule says. WCAG 2.2 success criterion 1.4.3 Contrast (Minimum) is Level AA and asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. The axe-core color-contrast rule tests 1.4.3. Where it cannot determine the background, such as a gradient or an image behind the text, axe reports the element as incomplete, for a person to review, instead of as a failure.
Expected: text that meets 4.5:1, checked by eye where software cannot measure it.
Who complies. Our page meets 1.4.3 wherever it can be measured, and both tools correctly leave the gradient text for a person to check.
What our audit found on the same page
- Score 100/100: 25 checks passed, 0 errors, 0 warnings.
- Contrast: 271 text elements and 33 control edges measured, all passing WCAG AA. 84 text elements are below the optional AAA level, reported separately and not scored.
- Images and graphics: all 9 images have alt text, and all 15 SVG graphics are named or hidden from screen readers.
- Links: all 86 have clear text, all 21 links that open a new tab say so, and the AAA link purpose check (2.4.9) passed.
- Keyboard and layout: focus visible on all 40 tab stops checked, the skip link tested with Tab and Enter, no sideways scrolling at 320px, text still fits at 200% zoom and with increased text spacing, and the page works in both orientations.
- axe-core: no violations from the axe rules it ran.
- Further pages: the pricing page and the blog, both with 0 errors and 0 warnings.
Side by side
- Violations: a11y-check.eu, 0. Our audit, 0.
- Left for a person to check: a11y-check.eu, 21 elements over gradients or overlapping. Our audit, 20 elements over images or gradients.
- Rules or checks passed: a11y-check.eu, 46 axe rules. Our audit, 25 checks, which include axe-core.
- Keyboard and layout tests: a11y-check.eu, none; axe tests code and colours, not behaviour. Our audit, keyboard focus, skip link, reflow, zoom, text spacing and orientation.
- Standard: a11y-check.eu reports against axe's WCAG rules. Our audit lists all 55 WCAG 2.2 Level A and AA success criteria, and says which still need a person.
- Pages: a11y-check.eu, the one page. Our audit, the home page plus two more.
- Cost: a11y-check.eu, free to run, with a PDF download. Our audit, £2.49.
Why this result matters
Accessibility checkers are only useful when they are honest about what they can and cannot measure. This month we have published false positives from TraceValid, Skynet Technologies and accessScan by accessiBe. a11y-check.eu is the first in this series to report no false positives on our home page. It reached the same verdict as our audit by a different route, and it marked the one thing it could not measure as needing review instead of calling it a failure.
That is what a good automated report looks like. It is also why no automated tool, ours included, can confirm every WCAG criterion on its own: some checks need a person.
How to read any automated accessibility report
- Separate failures from "needs review". Review items are not failures. They are things the tool could not decide.
- Look at the element and the reason. A good report says which element and why, as a11y-check.eu does.
- Know what the engine tests. axe-core tests page code and colours. It does not press Tab, zoom the page or resize it to a phone screen.
- Check the text over gradients by eye. Pick the lightest part of the gradient behind the text and check that the text is still clear.
Our Accessibility Audit costs £2.49. It checks the page in Chrome after its scripts run, against all 55 WCAG 2.2 Level A and AA criteria, reports AAA and best-practice notes separately and unscored, shows the evidence for every result, and lists which criteria still need a person to check. See a real report in our example accessibility report.
The full reports
Both reports used in this post are published in full and unedited: the a11y-check.eu report and our Accessibility Audit report for aiwebpageseo.com. See the full reports.
Sources
Frequently asked questions
Is a11y-check.eu accurate?
On our home page it was. It reported 0 violations, 1 item for manual review and 46 rules passed, and we found no false positives when we checked each line against the live page. Its one review item was text over a background gradient, where no automated tool can measure contrast reliably, and it correctly marked that for a person to check instead of calling it a failure. Our own Accessibility Audit reached the same result for the same text.
What does needs manual review mean in an axe-core report?
It means axe could not decide whether the element passes or fails, so it leaves the decision to a person. axe-core sorts results into violations, passes, incomplete and inapplicable. Incomplete results, often shown as needs review, are not failures. The most common case is colour contrast for text over a gradient or an image, because there is no single background colour to measure the text against, so someone has to check it by eye.
How do I check contrast on text over a gradient?
Find the lightest part of the gradient behind light text, or the darkest part behind dark text, and measure the text colour against that colour with a contrast checker. If the text meets 4.5 to 1 there, or 3 to 1 for large text, it meets WCAG 1.4.3 across the gradient. If it does not, darken or lighten the gradient behind the text, add a solid backing behind the text, or change the text colour.
What does axe-core not test?
axe-core tests the page's code and rendered colours against a set of rules. It does not press Tab to check that keyboard focus is visible, follow a skip link, zoom the page to 200 percent, increase text spacing, or resize the page to a phone width to check for sideways scrolling. Those tests need a real browser driven like a visitor would use it, which is why our Accessibility Audit runs them alongside the axe rules.
Why do some accessibility checkers report false positives and others do not?
Some checkers match patterns in the HTML and report anything that looks wrong, without checking what a browser and screen reader actually get, so they flag correct code. axe-core was designed to avoid false positives: when it cannot be sure, it reports the item as needing review instead of as a failure. A checker built on axe that shows its incomplete results honestly, as a11y-check.eu does, will usually agree with a careful manual check.