WCAG AA contrast ratio requirements for non-text elements and UI controls

Question

I'm trying to make sure I'm interpreting WCAG 2.0 AA contrast requirements correctly:

The visual presentation of text and images of text has a contrast ratio of at least 4.5:1

The minimum contrast success criterion (1.4.3) applies to text in the page, including placeholder text and text that is shown when a pointer is hovering over an object or when an object has keyboard focus. If any of these are used in a page, the text needs to provide sufficient contrast. Although this Success Criterion only applies to text, similar issues occur for content presented in charts, graphs, diagrams, and other non-text-based information. Content presented in this manner should also have good contrast to ensure that more users can access the information.

Does this mean that all text elements should have a minimum contrast ratio of at least 4.5:1, but non-text elements such as UI selection controls (checkboxes, radio buttons, switches, sliders, etc) have no contrast ratio requirement?

Reference: https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html

Answer 1

At level AA, SC 1.4.3 is not the only WCAG 2.1 success criterion related to contrast. SC 1.4.3 already existed in WCAg 2.0 and applied only to text. This left a loophole for many other types of content that are important for a user's understand but don't rely on text.

For this reason, WCAG 2.1 introduced SC 1.4.11 Non-text Contrast, which applies to user interface components and graphical objects. This success criterion also applies to "non-text elements such as UI selection controls (checkboxes, radio buttons, switches, sliders, etc)" (quoted from the question).

Understanding Success Criterion 1.4.11 contains many examples, such as buttons, check boxes, radio buttons, star rating widgets, and various types of graphical objects. The document does not contain a slider example, even though the success criterion applies also to that type of component (e.g. sufficient contrast for the thumb of a slider and obviously its values).

If you work in a jurisdiction that requires conformance to WCAG 2.1, SC 1.4.11 will apply. If you work in a jurisdiction that still requires conformance WCAG 2.0 and not yet to WCAG 2.1, SC 1.4.11 does not yet apply to your content, although it's a good idea to fulfil that requirement.

Answer 2

Christophe has given an excellent answer in understanding the rules. I would like to add something that was a bit too large for a comment.

Stop aiming for compliance and use WCAG as more of a checklist rather than a set of requirements

The key part of WCAG is the 'G' - Guidelines. They are written to guide and educate, not to be a hard set of rules (sadly, as then there wouldn't be so much confusion....but that is for another day! hehe)

So for the above example you have been made aware that colour contrast is an issue. Fantastic, now concentrate on questions such as 'How would someone who has low colour contrast perception use my site'

When you do that you need to rely on the WCAG less and more on logic. You have a button to control something? Then make sure it is high contrast.

Got an icon for an action? Make sure it is big enough for those with poor vision.

A better way to approach Accessibility (once you know the broad strokes of the WCAG) is to ask 'How would this item be accessed by someone:'

• with low contrast perception (ratio 4.5:1 or better yet 7:1)
• who is completely colour blind (colour not only way to convey meaning)
• who is Blind (does it need ARIA, are my ARIA tags and labelling correct, tested with Screen Reader?)
• who is Deaf (subtitles, transcripts and captions, BSL and ASL if you are really going for it!)
• who is mobility impaired (think Parkinsons - buttons big enough to click even with a shaky mouse / hand, enough white space on mobile to touch a scroll area without clicking a link when you have poor accuracy).
• who has an anxiety disorder (Simple design, can undo actions, nothing changes without explicitly saying so e.g. if filtering a list don't auto update, instead have an apply button (or warn it automatically updates so it is expected), no auto-playing videos, can switch off animations etc.)

• who has a learning disorder / cognitive impairment (Reading age of a 12 year old* - simple words, forms have labels so can see what has been filled in (covered by screen reader anyway), no complex Captchas etc.)

  • Reading age of a 12 year old as 1 in 5 Adults (in the UK at least) has the reading age of a 12 year old so don't alienate them - doesn't just help disabled people (as with most accessibility stuff)

If you are feeling extra brave think about people (severe mobility / quadriplegic) who are using eye gaze technology or speaking software (e.g. Dragon Naturally Speaking) to interact with your website.

If you think about people and focus more on HOW people interact and what REQUIREMENTS that individual may have you will be twice as good at accessibility with half the effort.

It then becomes a part of how you think when designing, you will leave enough room for buttons etc. you also start valuing semantics more (a <button> element as a button not a <div> - shocking!).

TL;DR - Sorry, bit of a rant there, hopefully you get the point of focusing on the people and their requirements and not the rules / guidelines