What are false positives in accessibility testing

Not everything that looks like an error really is one. That is the case with false positives. What are they, why do they occur and how can they be identified?

What is a false positive?

A false positive result occurs when a testing tool flags something as an accessibility error, but in reality it is not one. The element does not satisfy a certain rule, but it does not represent any real barrier for users.

Why do false positives occur?

Automated tools test accessibility against fixed rules. They check, for example, whether every:

  • image has an alternative text?
  • form element has a label?
  • iframe has a title attribute?

These checks are useful, but the tools do not understand context. They do not know that:

  • a hidden element (display: none) will never be seen by the user.
  • an element marked aria-hidden="true" is deliberately hidden from screen readers.
  • a technical form element such as <input type="hidden"> serves only for data transfer.

Typical examples of false positives

<iframe style="display: none;" src="https://chatbot.example.com"></iframe>

What the tool reports: The iframe has no title attribute, a screen reader user does not know what it contains.

Why it is not a problem: The iframe is completely hidden (display: none), the user never reaches it. The chatbot only appears after clicking a button, when the style changes to display: block and a title is added.

<input type="hidden" name="form_build_id" value="abc123">

What the tool reports: The form field does not have a correct autocomplete attribute.

Why it is not a problem: Hidden fields are technical elements for form management. The user does not see them, cannot type into them, and autocomplete makes no sense here.

<textarea  id="g-recaptcha-response"  style="display: none;" ></textarea>

What the tool reports: The textarea has no accessible label.

Why it is not a problem: This field is filled in automatically by JavaScript after CAPTCHA verification. It is hidden and the user does not interact with it.

How do we identify false positives?

We analyse the HTML code of reported issues and look for patterns indicating a completely hidden element:

  • display: none – the element is not rendered
  • visibility: hidden – the element is not visible
  • type="hidden" – a hidden form element

Note: aria-hidden="true" is deliberately NOT on the list. This attribute hides an element only from screen readers, while the element remains visible to other users. Errors such as aria-hidden-focus (a focusable element hidden from screen readers) are real accessibility problems.

Why don't we count these errors towards the score?

  1. Skewed results – A website with a chatbot would automatically score worse than a website without one, even though both are equally accessible.
  2. Demotivating site owners – Website administrators would see errors they cannot, or have no reason to, fix.
  3. A false sense of security – Fixing false positives would improve the score without any real accessibility improvement.
  4. Accuracy of the evaluation – We want the score to reflect real accessibility, not technical artefacts.

What do we do with false positives?

  • We do not count them towards the score – These errors are not included in the final evaluation.
  • We show them in the details – For transparency, we display them in the detailed report so that you can check them manually.
  • We label them – We clearly state that it is a false positive.
  • We update the list regularly – New patterns appear with new versions of tools and web technologies.

Automated testing has limits

False positives are one of the reasons why automated testing catches only 30–50% of real accessibility issues. A complete evaluation always requires:

  • Manual testing with a screen reader.
  • Testing keyboard-only operation.
  • User testing with people with various impairments.

The automated score is a useful indicator, but not a complete picture of a website's accessibility.