Recite Me Free Accessibility Scan: False Positives Explained

What happened

On 12 October 2026 we ran the free Recite Me accessibility scan on aiwebpageseo.com. It reported 186 issues: 104 at WCAG level A, 1 at level AA and 81 at level AAA.

On the same day our own accessibility audit scored the same page 100/100. It found no problems across 33 level A and AA success criteria.

Both tools can't be right. We checked every example the free report gave against the page code and the WCAG 2.2 text. Every level A and AA example was a false alarm. The 81 AAA items are not failures under any legal standard we know of. This post explains each one.

The short version

• 1.1.1 Non-text content, 28 flagged. These are decorative icons that are correctly hidden from screen readers. False alarm.
• 1.3.1 Info and relationships, 45 flagged. These are proper label elements tied to their inputs. False alarm.
• 1.4.3 Contrast (minimum), 1 flagged. This is logo text, which is exempt, and it passes as large text anyway. False alarm.
• 2.4.3 Focus order, 1 flagged. tabindex="0" keeps the natural tab order. False alarm.
• 4.1.2 Name, role, value, 30 flagged. Each radio button gets its name from its label. False alarm.
• 1.4.6 Contrast (enhanced), 81 flagged. This is level AAA, which is not required. The text passes level AA at about 5:1.

Finding 1: decorative icons (1.1.1, technique G100), 28 items

What the scan said. The footer social icons have no text alternative. Its example was an SVG with aria-hidden="true" and focusable="false".

What WCAG says. Success criterion 1.1.1 has a specific exception for decoration: "If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology."

What the page does. Each icon sits inside a link that already has an aria-label naming the destination. The icon itself is decoration, so aria-hidden="true" removes it from the accessibility tree. A screen reader announces the link name once, which is the correct result. If we added alt text to the icon as well, it would be read twice.

Why the scan got it wrong. Technique G100 is about giving a short text alternative to meaningful images. The scan appears to apply it to every SVG without checking whether the image is hidden or whether its parent link is already named.

Finding 2: form labels (1.3.1, failure F2), 45 items

What the scan said. Information is conveyed by presentation instead of structure. Its examples were the "Plain English" and "Technical" labels on our language switches.

What WCAG says. F2 is the failure "due to using changes in text presentation to convey information without using the appropriate markup or text". An example is making text bold to look like a heading instead of using a heading element.

What the page does. These are real label elements bound to their inputs with for and id attributes. That is technique H44, "Using label elements to associate text labels with form controls". It is the method WCAG recommends, not a failure.

Why the scan got it wrong. F2 is about missing markup. Here the markup is present and correct.

Finding 3: logo contrast (1.4.3, technique G18), 1 item

What the scan said. The "SEO" text in the footer logo does not reach 4.5:1 contrast.

What WCAG says. Success criterion 1.4.3 lists exceptions. One reads: "Logotypes: Text that is part of a logo or brand name has no contrast requirement." Separately, large text only needs 3:1. Bold text counts as large from 14 point, which is about 18.7px.

What the page does. The text is part of the AI Web Page SEO logo, so it is exempt. Even without the exemption, it is bold at 19px. That makes it large text, so the minimum is 3:1. It measures 3.2:1 and passes.

Why the scan got it wrong. The scan applied the 4.5:1 rule for normal text. It did not account for the logo exemption or for text size and weight.

Finding 4: focus order (2.4.3, failure F44), 1 item

What the scan said. The tab order is broken. Its example was our theme toggle, which has tabindex="0".

What WCAG says. F44 is the failure "due to using tabindex to create a tab order that does not preserve meaning and operability". It covers positive tabindex values (1, 2, 3 and so on) that force elements into an unnatural order.

What the page does. tabindex="0" does not change the order. It makes an element focusable at its natural place in the page. Our audit pressed Tab through 40 focus stops and confirmed each one was reached in order and visibly highlighted.

Why the scan got it wrong. It seems to treat any tabindex attribute as suspicious, whatever its value.

Finding 5: radio button names (4.1.2, technique G108), 30 items

What the scan said. The controls have no accessible name. Its examples were the radio inputs behind the Plain English / Technical switches.

What WCAG says. Success criterion 4.1.2 requires every user interface component to expose its name and role. For form inputs, a bound label element provides the name.

What the page does. The radio inputs are styled to look like a switch, but they are still in the accessibility tree. Each one gets its name from its label: "Plain English" or "Technical". Its role is radio and its checked state is exposed. Name, role and value are all present.

Why the scan got it wrong. It appears to check the input on its own and ignore the label that names it. The same switches were also behind the 45 items in Finding 2.

Finding 6: enhanced contrast (1.4.6, technique G17), 81 items

What the scan said. Text does not reach 7:1 contrast. Its examples were the status lines in our security strip, such as "No unsafe content found".

What WCAG says. 1.4.6 is a level AAA criterion. WCAG itself says: "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content."

What the law asks for. The UK Public Sector Bodies Accessibility Regulations and the European standard EN 301 549 both point to WCAG level AA. Level AA contrast is 4.5:1 for normal text. The flagged text measures about 5:1, so it meets the standard that actually applies.

Why it matters. These items are not errors. Counting them in a headline total makes a site that passes AA look like it has 186 problems.

Where the two tools agree. Our own audit now lists AAA contrast as an optional note that does not change the score. On the same home page it found 81 text elements below the AAA level, exactly the number the free scan reported. The two tools agree on AAA. They disagree only on A and AA, where every example the free scan gave was a false alarm.

Why two audits disagree

How the free scan works

It reads the HTML source and matches patterns. An SVG without alt text, an input without an attribute on itself, or a tabindex attribute are each flagged as a rule match. It does not see the page as a browser or screen reader does.

How our audit works

Our audit loads the page in a real Chromium browser and tests what users actually get:

• Names. It reads each control's computed accessible name, the same name a screen reader announces. Labels, aria-label and aria-labelledby are all taken into account.
• Contrast. It measures rendered colours and allows for large text and the logo exemption.
• Keyboard. It presses Tab through the page and checks that every stop is reachable, in order and visibly focused. On our home page that was 40 stops.
• Pages. It covered the home page, /pricing.html and /blog.

The 100/100 score means no problems across 33 level A and AA success criteria on those pages. AAA contrast is listed as an optional note and not scored, because no law we know of requires level AAA.

What this review can and can't say

• The free report shows only one or two examples per group, not all 186 items. We checked every example shown. The rest share the same criterion and technique code, so they are very likely the same pattern, but we cannot see them individually.
• The on-screen version of the scan also listed items that are not on our site, such as an image called MaryHeadshot1.jpg and a "Manage cookies" control. These did not appear in the PDF, so we have left them out here.
• Automated tools, ours included, cannot judge everything. Testing with real screen readers and real users is still the gold standard.

What we changed, and what we didn't

We changed nothing in response to this scan, because nothing failed. Two small tidy-ups would quiet pattern-based scanners without changing anything for users:

• Grouping each pair of language radios in an element with role="radiogroup" and an aria-label.
• Making the theme toggle a native button element instead of a div with tabindex="0".

How to check your own site

If a free scan hands you a long list of failures, check the examples before you start fixing:

• Is the "missing" text alternative on an image that is hidden or decorative?
• Is the "unnamed" control actually named by a label?
• Is the contrast item level AAA, or large text, or a logo?
• Is the tabindex value 0 or -1, rather than a positive number?

Or run our pay-as-you-go accessibility audit. It tests the rendered page in a real browser and lists each failing element. For more on labels, read Form Labels: Why aria-label Counts for Accessibility.

Sources

• Understanding SC 1.1.1 Non-text Content
• F2: using changes in text presentation without markup
• H44: Using label elements to associate text labels with form controls
• Understanding SC 1.4.3 Contrast (Minimum)
• Understanding SC 1.4.6 Contrast (Enhanced)
• F44: using tabindex to create a tab order that does not preserve meaning
• Understanding SC 4.1.2 Name, Role, Value
• WCAG 2.2 conformance requirements (note on Level AAA)

Frequently asked questions

Is the Recite Me free accessibility scan accurate?

On our site it was not. It reported 105 level A and AA issues, and every example it showed was a false alarm when checked against the WCAG 2.2 text. It flagged decorative icons that are correctly hidden with aria-hidden, form inputs that have proper label elements, logo text that WCAG exempts from contrast rules, and a tabindex of 0, which does not change the tab order. Its 81 AAA contrast items were accurate, but AAA is optional.

What are WCAG AAA items and do I have to fix them?

WCAG has three levels: A, AA and AAA. AAA is the strictest, for example 7:1 text contrast instead of 4.5:1. UK public sector rules and the European standard EN 301 549 ask for level AA, not AAA, and WCAG itself says AAA should not be required as a general policy for whole sites. AAA items are worth improving where you can, but they are not failures under those rules.

Why do two accessibility checkers give different results for the same page?

Some checkers read the HTML source and match patterns, so they flag things like an image without alt text even when it is correctly hidden. Others load the page in a real browser and check what a screen reader actually gets, such as each control's computed accessible name, rendered colours and real keyboard focus. The second kind gives far fewer false alarms.

Does an icon with aria-hidden fail WCAG 1.1.1?

No. WCAG 1.1.1 says decorative images should be implemented so assistive technology can ignore them, and aria-hidden set to true does exactly that. If the icon sits inside a link, the link needs its own accessible name, for example from an aria-label or visible text. An icon inside a named link should be hidden, or the name is read twice.