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.
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:
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
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
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).