A false positive in accessibility testing occurs when an accessibility test detects a barrier that is not actually present. False positives can occur for several reasons and under different circumstances.
A purely decorative image is one of the simplest examples of a false positive. According to the W3C's Success Criterion (SC) 1.1.1 Non-text Content, strictly decorative images, such as a graphic border or artistic accent images, should not have ALT text, so users of adaptive technologies like screen readers can ignore it. However, automated accessibility checkers will flag images without ALT text every time.
Another example of an area where false positives commonly occur is color contrast. Let's look at text color and background color. Without getting into the weeds of the science of color, transparency, which is the opacity of color, can play a part in possible false positives. The higher the transparency of a text color, the more the background color can bleed through the text. Some automated color contrast tools do not "understand" transparency; therefore, they can pick up the wrong color and report a false positive.
If you encounter what you believe to be a false positive with color contrast, you could consider using an eyedropper tool to get the HEX values for the "wrong color" and the contrasting color and conduct manual testing with a tool like Deque’s Color Contrast Analyzer.
When defining or choosing your colors, a good rule of thumb is to use the HEX or RGB values without using the CSS opacity property.
For DubBot users, you may have already experienced this next example, a false positive introduced by third-party code. The dreaded "YouTube Embeds Causing Flag for 'Elements must only use permitted ARIA attributes' is an issue that many of our clients have found. We detail it in this article from our Help Center.
We asked our own Support Engineer, Ashley Thompson, for her take on false positives with third-party code.
"Dealing with third-party code issues can be very frustrating. Developers have little or no control over how third-party embed code is written, and with something as widely used as YouTube, that can cause a significant problem. In this case, the false positive that was being flagged for our users was very much a barrier, but the relationship between the flagged issue itself and the corresponding success criteria was not immediately clear.
It was DubBot’s best attempt to flag an odd situation and in the end, it accomplished what you hope automated software will in an instance like this - get human eyes on the problem, leading to remediation and a more accessible website."
The issue is how YouTube codes the logo inside the video frame to make the "Subscribe" button appear on mouseover. It can't be navigated to using only a keyboard. Since the issue is with the code YouTube uses, not the code on your website, and you can’t access that code to remediate it, this is considered a false positive.
With that said, if you choose to use this embed type and want all users to have the ability to subscribe to your channel, you are responsible for creating an alternative access method to the Subscribe button.
A caveat we always like to include is that automated testing will only get you so far. Do not forget about manual testing.
If you encounter a false positive in your accessibility testing and have questions, please contact Ashley or another of our Support Engineers via chat or email at help@dubbot.com.
