The basics of visual accessibility
There are many accessibility guidelines to dictate the technical implementation and content creation of a website, but what about its visual user interface? In this article I will go over some easily overlooked accessibility requirements that deal with the visual design of a UI and give some advice on how to avoid the common pit-falls.
Accessibility is a process that needs to go through each stage of the service development in order to achieve a truly accessible service. It’s important that every member of the project team all the way from management to people working in continuous development has enough knowledge (or time to find out) about accessibility guidelines and best practices that affect their work. For designers and developers the main source of information is WCAG (Web Content Accessibility Guidelines) 2.1. In the following chapters I’ll introduce some parts of WCAG 2.1 that affect the visual aspects of a service and share my insights on how to complete them successfully. This is good to know for designers, developers and also clients looking to build an accessible service with a contractor.
Color accessibility
Most of the WCAG requirements are technical, but there are some rules for using colors too. My own experience from accessibility audits for both private and public clients is that these color related requirements are often the ones that are overlooked the most. There are of course logical reasons for this: many organisations get their color palette from an advertising agency that might not be aware of the WCAG guidelines or the client hasn’t specified that they need to be taken into account.
Designing an inaccessible color palette that is widely implemented and then having to fix it everywhere is of course much more expensive than doing things right from the start. That’s why my recommendation would be to consider accessibility guidelines as early as possible also when developing brand identity. Clients should either order their identity from a company that is familiar with WCAG guidelines or at least remember to specify that the requirements need to be met.
Accessibility guidelines for colors can be found under the first principle Perceivable in WCAG. In short, this principle requires organisations to produce web content in a format that can be perceived by the user. This principle actually contains a lot more than just the use of color: for example instructions on how to make content perceivable to users that can’t see the user interface in the first place. But let’s focus on the two color related requirements in this chapter.
The first guideline dictates that functionality or important information should not be indicated by the change of color alone. In practice, this means that for example links should not be differentiated from the body text just by a different color. A designated link color can be used, but in addition, another visual effect like an underline should be used.
“Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.”
The other requirement deals with the minimum contrast ratio between the colors used. For this there are two levels: the minimum AA level and the improved AAA level. The so-called double A level is the basis for both EU Web Accessibility Directive and Finnish Act on the Provision of Digital Services aka the national accessibility law. It dictates that the contrast ratio of background and foreground color in text should be at least 4,5:1. Exceptions to this are large text (basically headers) or graphical objects that can have a contrast ratio of 3:1 and illustrations or brand logos that don’t have contrast requirements.
The contrast ratio might sound like advanced maths, but luckily there are handy tools for calculating it. One of them is this color contrast calculatoropens-in-a-new-tab that allows you to feed in the background and foreground color and analyses whether they pass or fail at the different levels.
If you want to go beyond the legally required AA level, one good practice is to allow users to choose or at least adjust the background and foreground colors to suit their own preference. A great way to do this is to add a dark mode (or a light mode, depending on which way the user interface colors are by default) where a light background is turned to dark and dark texts are turned to light. This is particularly helpful to users who suffer from glare from large bright surfaces. Some operating systems and browsers have built-in dark modes that force a color change on the interface, but the results might not be optimal because the change is, as said, forced. So a better way would be to design both dark and light mode that work on your site in a more controlled way.
Visual consistency
Given the changing technologies, it would be pretty hard to give tangible guidelines on how to use visual components apart from the use of color. However, under the principle Understandable, there is a guideline called Predictable, that instructs us to create web pages that appear and operate in predictable ways. This guideline contains criterion such as:
"Components that have the same functionality within a set of Web pages are identified consistently."
From the visual point of view, this could mean for example that all filters throughout the site look the same (and not for example like dropdowns on one page and checkboxes on another). This is of course not only an accessibility guideline; it’s also good usability and just common sense. But even though the guideline is so simple and it makes so much sense, following it might prove to be difficult without proper measures.
A good example of a situation where visual consistency can be compromised is when a website is being developed over a long period of time. Without the involvement of a well-maintained design system, there is always a danger of adding new features that contain elements that are not in line with the existing components. Sometimes new components get added without any particular consideration too when developers use different libraries to create a new functionality. Using libraries is a good and effective way to save on development costs and speed up the development process as such. But you need to be careful that before you notice, the interface doesn’t contain multiple elements that look different but in the end, do the same thing.
That’s why creating and maintaining a design system is advisable not only because of usability and visual identity but also because of accessibility. Another benefit of a living, well-curated design system is that an accessible implementation of each component can be documented in the system. This way, developers have access to accessible components whenever they add something new to the interface, and new designers and developers can quickly learn the correct way to implement different components.
User interface components should also be designed so that their visual appearance communicates their hierarchy. A simple example of this would be that a header on a higher level appears bigger or bolder than a header on a lower level. Again, this is a kind of an obvious guideline, but it’s worth mentioning because in practicality, there can always be cases where the hierarchy of different components can be blurred. On a higher level, it may be easy to determine what the relationships between different components are, but when getting down to a more detailed level the hierarchy can become increasingly blurred. It’s often a good idea to check your assumptions by conducting user tests or interviews to find out what is the most valuable information to your users.
I was recently involved in a project where we designed an app for students in higher education where we needed to display some course data. Originally, the assumption was that the name of each course was the most important information to display, but in user tests, we discovered that, actually, what students found most valuable was the information about the time and place of the course. This was due to the fact that they mostly wanted to use the app to check where they had to be at a certain time. So, as a result, we re-evaluated the relationship between the less noticeable tags for time and place and the bigger course name headers.
This last example was, strictly speaking, maybe more in the field of general usability than accessibility, but good usability is often good accessibility, so it makes sense to look at these topics together.
Additional resources
Of course, in addition to WCAG, there are many useful accessibility resources out there. And a lot can be learned from just pure experience and the collective knowledge of the accessibility community. To try and spread out some of the knowledge we have accumulated, Wunder’s accessibility team has put together a collection of Wunderpedia articles related to various accessibility topics - such as Accessible UIs, Accessibility terminology and Accessibility testing.
In these articles you can find practical information and advice we have gathered on accessibility, so don’t forget to check them out for some further reading!
Do you wish to get your site audited for accessibility or aim to have more accessible digital services?
We are more than happy to help you. Leave your contacts details and let’s develop digital that always serves the user and the purpose.