Home / Blog / accessScan by accessiBe: False Positives Explained

Site Audit

accessScan by accessiBe: False Positives Explained

13 October 2026 · AI Web Page SEO

accessiBe's accessScan rated the aiwebpageseo.com home page accessible but listed five failures and a title-attribute warning, and all six were false positives: the content it said was outside the main landmark is inside it, a second check contradicted the first, aria-current is not needed on logo links, hiding decorative emoji icons with aria-hidden is correct practice, one flagged element was an empty body tag, and the links it said were named only by a title attribute already had screen-reader text or visible text.

What happened

On 13 October 2026 we ran accessScan, the free accessibility checker from accessiBe, on the aiwebpageseo.com home page. Its verdict: "Accessible. Congratulations! Our scan indicates that your webpage is accessible." It ran 60 WCAG checks and 13 best-practice checks, and passed most of them.

It still listed five failures and two best-practice warnings. We checked each one against the live page's code. All five failures were false positives, and so was one of the two warnings. This post goes through them one by one, with the code.

The short version

"Main landmark" (2 failures): false positive. All our page content is inside <main>, and the two failures contradict each other.
aria-current="page" (3 failures): false positive. Logo links to the home page do not need it.
aria-hidden on visible content (14 failures): false positive. They are decorative emoji icons, and hiding them is correct.
"Visually hidden but exposed" (1 failure): false positive. The flagged element was an empty <body></body>.
Title attribute as the only label (best practice): false positive. All seven links it flagged already had a proper name: six share links with screen-reader text, and a Changelog link with visible text.
Mail links (best practice): optional advice, not a WCAG requirement.

False positive 1: "the main content is not in the main landmark"

What the report said. "The main landmark represents the primary content of a page" failed, on this element:

<section id="proven" class="sec-compact sec-proven"> ... <h2>Established audits</h2>

What the page has. That section is a child of <main id="main-content">. We loaded the live page in Chrome and listed the children of <main>: the security-check strip, the hero, and the three audit sections, Established audits, Final checks and Work in progress. The navigation and the footer sit outside it. That is exactly what WCAG technique ARIA11 and the HTML standard describe: one <main>, holding the content unique to the page.

What the rule says. The HTML Standard (WHATWG) defines <main>, and W3C technique ARIA11: Using ARIA landmarks to identify regions of a page describes the main landmark as "a region that contains the main content of a document". ARIA11 is a sufficient technique for WCAG 2.2 success criteria 1.3.1 Info and Relationships and 2.4.1 Bypass Blocks.

Expected: one main landmark holding the content unique to the page, with repeated parts such as the site navigation and footer outside it.

Who complies. Our page complies: one <main>, containing every content section, with the navigation and footer outside. accessScan's check does not match the rule: it reports a section inside <main> as outside it.

False positive 2: "an element without main content is tagged as main"

What the report said. The second landmark check failed on our <main> element itself.

Why it cannot be right. The first check says our main content is outside <main>. The second says <main> has no main content. Both cannot be true, and the page's code shows neither is. Our <main> opens with two <meta> tags (structured data for the list of tools) and contains a <header class="hero">. Both are valid HTML inside <main>, and our best guess is that the scanner's rules are confused by one of them.

What the rule says. The same W3C technique applies, and the W3C HTML reference for the header element says it "can be used where flow content is expected", which includes inside <main>. Its only restriction is that a header cannot contain another header or a footer.

Expected: a main landmark with the page's main content. Nothing forbids a <header> or a <meta> inside it.

Who complies. Our page complies. accessScan's check does not: it fails the same <main> for the opposite reason to the check before it.

False positive 3: aria-current="page" missing on 3 links

What the report said. Links to the current page should carry aria-current="page". It flagged our header logo, our footer logo and our "Microsoft Edge" safety-check link, all of which point to the home page.

Why that is wrong. aria-current exists to tell screen reader users what sighted users can see: which item in a set of links is highlighted as the current page, such as a menu or breadcrumb. No WCAG success criterion requires it on a logo, and our logos are not highlighted as "current". The Edge link points to our home page because it is the link Microsoft Edge's SmartScreen check is run against. It is not a navigation item at all.

What the rule says. W3C's WAI-ARIA specification defines aria-current as indicating "the element that represents the current item within a container or set of related elements". MDN's guidance adds that it should be used when one element in a group, such as a breadcrumb or the steps of a checkout, is styled differently to show sighted users it is the current one.

Expected: aria-current on the one highlighted item in a menu, breadcrumb or set of steps. No WCAG 2.2 success criterion requires it on a logo or any other link.

Who complies. Our page complies: none of its links is styled as the current page. accessScan's check asks for something the rule does not require.

False positive 4: aria-hidden on visible content (14 failures)

What the report said. 14 elements were visible but hidden from screen readers, for example:

<div class="ic" aria-hidden="true">♿</div>

Why that is wrong. Each one is a decorative emoji icon beside an audit card whose heading already says what the card is. W3C's guidance is that decorative images should be hidden from assistive technology. Left exposed, a screen reader would read "wheelchair symbol" or "shield" before each heading, adding noise and no information. Hiding them is the correct practice, not a failure.

What the rule says. WCAG 2.2 success criterion 1.1.1 Non-text Content (Level A), in its "Decoration, Formatting, Invisible" exception, says that 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". W3C's decorative images tutorial gives the same advice.

Expected: decorative icons hidden from screen readers. aria-hidden="true" is the standard way to do that.

Who complies. Our page complies. accessScan's check fails the exact practice WCAG asks for.

False positive 5: "visually hidden but still exposed"

What the report said. One failure, and the code it showed was <body></body>, an empty body element. Our page's body is not empty. The most likely explanation is that the scanner picked up an empty frame or an element it could not read, and reported it as a page problem.

What the rule says. Neither WCAG 2.2 nor WAI-ARIA has a rule about an empty <body> being "visually hidden but exposed".

Expected: nothing. There is no content in an empty element for anyone, sighted or not, to perceive.

Who complies. Nothing to comply with: the page's real body is full of content, so this is a fault in the scan, not in the page.

False positive 6: links labelled only by a title attribute

What the report said. accessScan does not score this, and lists it as best practice: the title attribute is read out inconsistently by screen readers, so it should not be a control's only name. It flagged seven links: our six share links and our Changelog link.

What the page has. None of them relies on title. Each share link already contains its own name for screen readers, in text that is hidden on screen but read aloud:

<a href="https://twitter.com/intent/tweet?..." title="Share on X" ...><svg aria-hidden="true">...</svg><span>X</span><span class="sr-only"> — share this page (opens in a new tab)</span></a>

A screen reader announces that link as "X — share this page (opens in a new tab)". The title is extra help on top of a real name. The Changelog link is the same: it has visible text, "Changelog", and its title, "See what changed in this release", only adds to it. That is exactly how the report itself says title should be used.

Mail links. Its other best-practice note asks for a warning before a link opens the visitor's email app. That is reasonable advice, not a WCAG requirement, and our "Share by email" link now says "opens your email app".

What the rule says. W3C's Accessible Name and Description Computation 1.2 sets the order in which browsers work out a link's name. Name from content comes first; the title attribute is step 2I, the last fallback: "Tooltip attributes are used only if nothing else, including subtree content, has provided results." W3C technique C7: Using CSS to hide a portion of the link text is a sufficient technique for WCAG 2.4.4 Link Purpose (In Context): it adds link text that is hidden on screen but read by screen readers, exactly as our share links do.

Expected: every link has an accessible name. Hidden link text is a recognised way to give one, and when it is there, title is not used as the name at all.

Who complies. Our page complies: every flagged link takes its name from its own text. accessScan's check does not follow the name computation: it treats title as the only label when the content already names the link.

What UK law expects

This is general information, not legal advice.

Public sector websites must meet WCAG 2.2 Level AA and publish an accessibility statement, under the Public Sector Bodies Accessibility Regulations 2018. The GOV.UK monitoring guidance sets out the standard and how sites are checked.
Businesses and charities are covered by the Equality Act 2010, which requires service providers, including through a website, to make reasonable adjustments so disabled people are not put at a substantial disadvantage. The Act names no technical standard; WCAG 2.2 Level AA is the yardstick used.
What is measured is the page itself: its code, as the success criteria and techniques above describe. A scanner's score is evidence only as far as its checks match those rules.

Judged against those rules, our home page complies on every point accessScan raised. For more, see Is WCAG a legal requirement in the UK?

About accessScan and accessWidget

accessScan is a free lead-in to accessiBe's paid product, accessWidget, an overlay: a script that adds a toolbar and makes changes in the visitor's browser, while the site's own code stays as it was. In April 2025 the US Federal Trade Commission finalised an order requiring accessiBe to pay $1 million, over claims that its AI-powered tool could make any website compliant with WCAG. Fixing the page's own code is the only way to meet WCAG.

How to read any automated accessibility report

Look at the code it shows you. If the snapshot does not match the claim, such as a section that is inside <main> or an empty <body>, it is a false positive.
Check which failures are WCAG and which are best practice. Best-practice notes are worth reading, but they are not conformance failures.
Watch for contradictions. Two checks that cannot both be true mean the rules are guessing.
Be wary of an overlay as the fix. A toolbar does not change your page's code.

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 best-practice notes separately and unscored, and lists which criteria need a person to check. See a real report in our example accessibility report.

Sources

Try it yourself: Accessibility Audit · Example report

Frequently asked questions

Is accessScan by accessiBe accurate?

On our home page it reached the right verdict, accessible, but every failure it listed was a false positive. It said a section was outside the main landmark when it is inside it, flagged decorative emoji icons for being hidden from screen readers, asked for aria-current on logo links, reported an empty body tag, and said seven links were named only by a title attribute when each already had screen-reader text or visible text.

Should decorative icons be hidden with aria-hidden?

Yes. W3C guidance is that purely decorative images should be hidden from assistive technology so screen reader users do not hear noise. An emoji beside a heading that already says what the section is adds nothing when read aloud, so aria-hidden="true" is correct. A checker that fails visible content for being hidden cannot tell decoration from information, so check what each flagged element actually is.

Does a logo link need aria-current="page"?

No WCAG success criterion requires it. aria-current tells screen reader users which item in a set of links, such as a menu or breadcrumb trail, is visually marked as the current page. A logo that links to the home page is not marked that way, so there is nothing for aria-current to convey. Use it on navigation menus and breadcrumbs that highlight the current page.

Does an accessibility overlay like accessWidget make a website WCAG compliant?

An overlay adds a script and toolbar that change the page in the visitor's browser, but it does not change the site's own code, which is what WCAG conformance is judged on. In April 2025 the US Federal Trade Commission finalised an order requiring accessiBe to pay $1 million over claims that its AI tool could make any website WCAG compliant. Fixing the page's code is the reliable route.