Home / Blog / TraceValid Accessibility Checker: False Positives Explained

Site Audit

TraceValid Accessibility Checker: False Positives Explained

25 October 2026 · By John Carlsson

TraceValid's free trial report on the aiwebpageseo.com home page showed two failures, both under WCAG 1.1.1 and both on the same image: a Google Safe Browsing badge written as an ordinary img tag that loads an SVG file. It asked for role="img" and an aria-label. Both were false positives. An img element is already an image to screen readers, its alt text is its accessible name, and the W3C's own HTML validator reports role="img" on an img element as unnecessary. Our Accessibility Audit scored the same page 100/100 against WCAG 2.2.

What happened

On 25 October 2026 we ran the free trial of TraceValid, a multi-page web accessibility checker, on the aiwebpageseo.com home page. It tests against WCAG 2.1 and says it covers WCAG 2.2, 2.1 and 2.0, the ADA, Section 508, AODA, EAA/EN 301 549 and others. The trial counted 44 pages to check and showed results for one of them.

The trial showed five rows for the home page. Three were images marked "conditional passed, manual check", asking a person to confirm the alt text. The other two were failures, both under WCAG 1.1.1 Non-text Content, Level A, and both on the same image. The rest of the report was locked behind an order of CAD $22.50 for 45 pages.

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 checked both of TraceValid's failures against the live page's code and the W3C's own rules. Both were false positives. This post explains why, with the code.

The short version

"Missing role attribute with img value for SVG" (1 failure): false positive. The element is an ordinary <img> tag, which already has the image role. The W3C's HTML validator reports adding role="img" to it as unnecessary.
"Missing aria-label attribute for SVG" (1 failure): false positive. The image's alt text is its accessible name. An aria-label would only repeat it.
Both failures are on one element. The same badge is failed twice, once for each attribute, under the same success criterion.

The element TraceValid failed

Both failures point to line 1097 of the page, a small badge showing that Google Safe Browsing found no unsafe content:

<img class="ts-badge" src="/google-safe.svg" alt="Google Safe Browsing: no unsafe content found" width="88" height="31">

The picture happens to be stored as an SVG file, but the element on the page is an <img> tag, the same as any JPEG, PNG or WebP image. TraceValid's own report lists it under "Element Type: Images", and gives it a "conditional passed" for its alt text in the row just above the two failures.

False positive 1: "Missing role attribute with img value for SVG"

What the report said. "Missing role attribute with img value for SVG. This will cause screen readers to just consider it as a single entity and describe it using the label. An SVG is not image, it is a graphics-document."

Why that is wrong. That advice is about SVG code written directly into a page with an <svg> tag. An inline <svg> can contain links, text and other parts, so screen readers may treat it as a graphics document, and authors often add role="img" to make it read as one picture. None of that applies here. An <img> tag loads the file as a single picture, whatever format the file is in, and browsers already expose it to screen readers as an image. Treating it as "a single entity described by its label" is exactly what should happen to a badge.

What the rule says. The W3C's ARIA in HTML specification gives an <img> with alt text the implicit role img, and says that setting a role that matches an element's implicit role is not recommended. The W3C's Nu HTML Checker reports it as a warning: "The img role is unnecessary for element img." MDN's guidance on the img role describes it as a way to group content, such as inline SVG or several elements, into one image.

Expected: an <img> element with meaningful alt text. No extra role is needed.

Who complies. Our page complies. TraceValid's check asks for markup the W3C's own validator warns against.

False positive 2: "Missing aria-label attribute for SVG"

What the report said. "Missing aria-label attribute for SVG", with the same explanation as the first failure.

Why that is wrong. The badge already has an accessible name: its alt text, "Google Safe Browsing: no unsafe content found". That is the text a screen reader reads out. An aria-label would replace the alt text as the name, so the best it could do is repeat it word for word. The worst is that the two drift apart over time and visitors hear something different from what the alt text says.

What the rule says. WCAG 2.2 success criterion 1.1.1 Non-text Content (Level A) requires a text alternative that serves the same purpose as the image. W3C technique H37: Using alt attributes on img elements is a sufficient technique for it. The first rule of ARIA in the W3C's Using ARIA guide is to use the native HTML feature where one exists, instead of adding ARIA.

Expected: alt text that describes the image. H37 is met, and 1.1.1 is met.

Who complies. Our page complies. TraceValid's check asks for an extra attribute that WCAG does not require and that adds nothing for screen reader users.

What our audit found on the same page

Our Accessibility Audit loads the page in Chrome with its scripts running and tests what visitors actually get. On the aiwebpageseo.com home page it reported:

Score 100/100: 25 checks passed, 0 errors, 0 warnings.
Images: all 9 have alt text, and all 15 SVG graphics are named or hidden from screen readers.
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.
Links: all 86 have clear text, all 21 links that open a new tab say so, and the selected AAA check for link purpose (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.
Further pages: the pricing page and the blog, both with 0 errors and 0 warnings.

It also lists all 55 WCAG 2.2 Level A and AA success criteria, and says which ones still need a person to check. No automated tool can confirm every criterion on its own.

Side by side

Standard tested: TraceValid, WCAG 2.1. Our audit, WCAG 2.2, with all 55 Level A and AA criteria listed.
Failures on the home page: TraceValid, 2, both false positives. Our audit, 0.
Results shown: TraceValid, 5 rows, with the rest locked. Our audit, the full report.
Real-browser tests shown: TraceValid, none. Our audit, keyboard focus, reflow, zoom, text spacing, orientation and the skip link.
Contrast: TraceValid, not shown in the trial. Our audit, 271 text elements and 33 control edges measured.
Cost to see the full report: TraceValid, CAD $22.50 for 45 pages. Our audit, £2.49 per audit.

A second page

We also ran both tools on grabzies.co.uk/shop. TraceValid's trial showed three rows: two images left for a manual check and the page title passed. It found nothing to fix in what it showed, and quoted CAD $4.50 for 9 pages to see the rest. Our audit listed every result for that page, including real problems we then confirmed in the live code: no navigation landmark, two "Chat with us" links with the same text going to different places, and two links that open a new tab without saying so. Each came with how to fix it.

What the law expects

This is general information, not legal advice.

United Kingdom: public sector websites must meet WCAG 2.2 Level AA under the Public Sector Bodies Accessibility Regulations 2018, as the GOV.UK monitoring guidance explains. Businesses and charities are covered by the Equality Act 2010, which names no technical standard; WCAG Level AA is the yardstick used.
European Union: the European Accessibility Act applies to many products and services sold to EU consumers, and its harmonised standard, EN 301 549, is based on WCAG Level AA.
United States and Canada: the ADA, Section 508 and Ontario's AODA all point to WCAG Level AA, in different versions.

Every one of these is measured against the page itself, through the WCAG success criteria and the W3C techniques above. A scanner's failure is only evidence when its check matches those rules. For more, see Is WCAG a legal requirement in the UK?

How to read any automated accessibility report

Look at the code it shows you. Here, the code was an <img> tag, and the failure text was about inline SVG. When the snapshot does not match the claim, it is a false positive.
Check the rule it cites. If the W3C's own validator warns against the fix a scanner asks for, the scanner is wrong.
Count by element, not by row. One element failed twice is one question to answer, not two problems.
See what you get before you pay. A trial that shows a few rows and locks the rest cannot tell you whether the paid report is any more accurate.

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 optional AAA and best-practice notes separately and unscored, and lists which criteria still need a person to check. See a real report in our example accessibility report, and our earlier test of another free checker in accessScan by accessiBe: False Positives Explained.

The full reports

Every report used in this post is published in full and unedited: both TraceValid trial reports and all three of our Accessibility Audit reports, for aiwebpageseo.com and grabzies.co.uk/shop. See the full reports.

Sources

Try it yourself: Accessibility Audit · Example report

Frequently asked questions

Is the TraceValid accessibility checker accurate?

On our home page, its free trial was not. It showed two failures, both under WCAG 1.1.1 and both on the same image, and both were false positives. It treated an ordinary img tag that loads an SVG file as if it were SVG code written into the page, and asked for role="img" and an aria-label. The image already had the image role and clear alt text, which is what WCAG technique H37 asks for. The rest of its report was locked, so we could not check anything else it found.

Does an img tag that loads an SVG file need role="img"?

No. An img element already has the implicit role img, whatever format the image file is in, and browsers expose it to screen readers as an image. The W3C's ARIA in HTML specification says setting a role that matches an element's implicit role is not recommended, and the W3C's Nu HTML Checker warns that the img role is unnecessary for element img. The role="img" advice applies to SVG code written directly into a page with an svg tag, which can contain links and text.

Should an image with alt text also have an aria-label?

No. The alt attribute is the image's accessible name, and it is the text a screen reader reads out. An aria-label would replace the alt text as the name, so at best it repeats it, and at worst the two drift apart and screen reader users hear something different from what the alt text says. The first rule of ARIA, in the W3C's Using ARIA guide, is to use the native HTML feature where one exists. For images, that is the alt attribute.

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

Some checkers read the HTML source and match patterns, so they can flag an element by its file type or tag without checking what a screen reader actually gets. Others load the page in a real browser with its scripts running, and test the computed accessible names, rendered colours, keyboard focus, zoom and reflow. The second kind gives far fewer false positives. Always look at the code a report shows you, and check it against the WCAG success criterion and W3C technique it cites.

Is a free accessibility trial enough to check a website?

A trial that shows a few rows and locks the rest cannot tell you much. On our home page, TraceValid's trial showed five rows out of 44 pages counted, and both of its failures were false positives. You cannot judge whether the paid report is more accurate from that. A useful report shows every result with the code behind it, separates WCAG failures from best-practice notes, and says which success criteria still need a person to check, because no automated tool can confirm all of them.