This is one of the success criterions that can perplex many readers. It is because this success criterion is extensive, and a good number of web page elements fall under its scope. Based on the context of these element types, it may require different aspects to be considered while testing. Lets take a look at these requirements in this 1st blog in the Non-text contrast series.
Some of us must have wished for an automated tool that could completely test a webpage for these requirements. That would make this task so much easier. But sadly, there is no such tool. While it is possible to automatically compute contrast ratio of some non-text elements, but it would need that colour (hex codes) is identified from CSS. Without colour identification, tools will struggle to find the right ratio. We will have to wait till such a tool with strong AI is developed. Anyway, understanding the success criterion is much more fun and manual testing is much more reliable.
In a nutshell, testing of contrast for non-text elements cannot be relied on automated tools. It requires manual testing to ensure that all required web page elements are thoroughly tested. It needs human judgement to ensure that only the elements in scope are examined.
As opposed to the title of this blog so far, we have only made it seem even more daunting. So, now let’s try and simplify it by logically dissecting and grouping its requirements. We shall also address the dilemma while testing contrast requirements of the infamous focus indicator.
As the success criterion is quite extensive, we will decode it in a series of blogs.
Overview of Success Criterion 1.4.11 Non-text Contrast
This success criterion was newly introduced in WCAG 2.1 in June 2018. It has been placed under the guideline 1.4 “Distinguishable” which is a part of the principle “Perceivable”. It has WCAG conformance Level of (AA), the minimum conformance level that products should try to achieve. Conforming with this success criterion ensures people with visual impairment, especially low vision users can identify important non-text information.
User Interface Components
Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.”
As the name itself suggests, it requires that non-text elements have sufficient contrast. Note that any form of text is separately tested for contrast under WCAG Success Criterion 1.4.3 Contrast (Minimum).
Talk to our Accessibility Expert
Basic Understanding for Testing
In general terms we can say, all informational non-text elements MUST have a minimum contrast ratio of 3:1 with its adjacent colours. Non-text is considered informational when it is relied upon to identify or understand the purpose of a component. From the normative definition, statements and examples on the understanding page, here is a derived methodology for finding contrast ratio of non-text elements.
Non-text contrast testing methodology key requirements checklist:
- Informational or Not – Find out if the non-text element is informational or not. If yes, proceed further. If no, not required to test further.
- Non-text Identification – Find out the key parts of non-text element that help in its identification or determining its purpose or both.
- Non-text element Colour – Find out the colour (hex code) of the identified non-text element.
- Adjacent Colour – Identify the adjacent colours (hex code) of non-text element which will impact its identification.
- Contrast Check – Check if the minimum contrast ratio requirement is met i.e., 3:1 or above between the non-text element and its adjacent colour. Contrast ratio can be found using any contrast checker tool.
* Key point to identify the adjacent colour Adjacent colour is the colour next to the component. To identify the adjacent colour appropriately, it is critical to first identify the component itself. Adjacent colour may be identified differently based on the non-text element that needs to be tested.
For example, in case of a bordered input field with white internal and external background, the border becomes the key for identifying the input field. Hence, the border encompassing the white internal background helps to identify the component and white colour external background outside this border becomes the adjacent colour of the component.
In another example, a bordered input field has a dark external background and light internal background. The input is majorly identified based on the light internal background as the border gets visually absorbed within the dark external background. Hence, the light internal background becomes the component and dark coloured external background outside the input becomes the adjacent colour.
Basically, when a component is identified its surroundings with best possible contrast become its background. This contrast ensures its identification. Thus, the background provides us with the adjacent colour to find the contrast ratio.
CSS Hex Code vs Picker Hex Code
For accuracy, it is always recommended to take the hex codes of colours from the CSS whenever available. If the colour is not defined through CSS, then we should use the colour picker to find out the colours hex code.
Sometimes authors use the CSS property of ‘opacity’ to lighten the elements. In such cases a contrast tool that also considers the opacity (alpha value) should be used for computing the contrast ratio. Another way but not an ideal way would be to use a colour picker to directly find out the hex code of the colour with reduced opacity.
So far, we have covered the initial understanding and requirements of the success criterion. Other aspects and key areas of this success criterion will follow the same understanding. The same logic will be applied based on the component type. We shall apply the testing methodology on few examples in the upcoming blogs. Also, we shall discuss in more detail about testing graphical objects and user interface components along with their states in these blogs. So, watch out for the next blogs in the series!
This article by Salim Khan is a part of our BB Geek series where BarrierBreak team members share their expertise on accessibility and inclusion, drawing from their extensive experience in the field.