When learning about accessibility, designers and developers often assume that the best practice is to give people more options. It’s true that certain fonts and color combinations are less accessible for some users with disabilities, so it’s reasonable to assume that more controls make for a better experience.
This is partially true. As we’ve discussed on this blog, people appreciate options. However, your core web experience must be as accessible as possible. If that’s not the case, you should concentrate on that core experience before adding new controls.
In short: Adding new controls isn’t a shortcut for making your website conformant with the Web Content Accessibility Guidelines (WCAG) or the dozens of international non-discrimination laws that use WCAG as a framework. Here’s why.
Providing controls for font, font size, and color is helpful — if users can find the controls
Let’s tackle the core question: Does providing controls help your website follow WCAG’s requirements for color contrast, font size, and other appearance-based criteria?
Kind of, but not really. By providing text controls for your users, you’re essentially providing an alternate version of each webpage where the controls appear. WCAG supports “conforming alternate versions.” However, this approach introduces an unnecessary degree of complexity:
- Users who prefer a certain font or color combination may not need extra controls. They can change the settings with their web browsers, screen magnifiers, or with other technologies.
- Depending on the implementation, your text controls might prevent these other methods from working predictably. You’ll need to test with different browsers to make sure that your users have the same level of control.
- The mechanism that controls text appearance must also be accessible.
- People also need to be able to read the instructions for the controls. If your website fails WCAG’s color contrast requirements, the text may be illegible (and your users won’t even know that the option exists).
Just as you can’t satisfy WCAG by providing a “dark mode" version of your web page, you shouldn’t try to satisfy all visual requirements by providing options. Making the default version of your website accessible — at least in terms of color contrast and font size — is much, much safer (and much better for your users).
Related: Use of Color for Accessibility Explained
But doesn't WCAG require that "foreground and background colors can be selected by the user?"
Yes and no. This language comes from WCAG Success Criterion 1.4.8, which reads, in part:
For the visual presentation of blocks of text, a mechanism is available to achieve the following … Foreground and background colors can be selected by the user.
That criterion also requires a mechanism for justifying text, and contains a few other requirements for visual presentation.
However, this is a Level AAA criterion — most websites should aim for Level AA conformance (learn more about WCAG conformance levels). Additionally, the language of the requirement specifically notes that websites do not need to provide the mechanism in question:
Content is not required to use these values. The requirement is that a mechanism is available for users to change these presentation aspects. The mechanism can be provided by the browser or other user agent.
To put that another way: As long as your content doesn’t prevent the user from changing the foreground and background colors on their own, you’re still meeting the requirement.
Related: 4 Digital Accessibility Features That Benefit Everyone
If your website is already WCAG conformant, text controls can be a great way to support your users
We don’t want to give the wrong message here: If you can provide accessible, intuitive controls for your users, you should do so! It can be a great way to accommodate people and support a certain level of customization. These days, there are plenty of extensions available that can provide that functionality in an accessible way.
The bottom line, however, is that you can create a more usable website by ensuring that the default version of your content conforms with WCAG. That’s particularly true for WCAG’s color contrast requirements, which can be met fairly easily (and AudioEye’s Color Contrast Checker can make that process even easier).
