Previously on Wunder’s blog, we talked about how accessibility is a human right. Modern devices elevate human efficiency and capabilities to new levels. We need to make this brave new digital world work for everyone. Make sure your website supports different ways of accessing and using it. Close to one billion people in the world have some form of disability. By ensuring that your digital services are accessible, you make your services available for everyone.
Unfortunately, accessibility and assistive technologies can very easily feel like an unknown world at first. Where to begin? The process of learning about accessibility and how to test it can feel overwhelming at first. Especially overwhelming are the global guidelines at the center of web accessibility: Web Content Accessibility Guidelines 2.1 or – as it is commonly referred to – WCAG 2.1.
If you’ve never heard of WCAG before, it’s a list of guidelines used to evaluate whether a website is accessible or not. It’s also used to determine if a website is legally accessible or not. The new EU accessibility legislation that is now in effect in its member countries leans on WCAG. It’s fair to say that the web section of this legislation is basically a compact version of WCAG 2.1.
Reading through all of the over 80 guidelines in WCAG 2.1 right away is not very effective: there are hundreds of pages to read. Way more efficient way is to start by embracing the core of WCAG, that would be the four principles, aka POUR.
As lovely as it would be, POUR has nothing to do with coffee or any other beverage. Instead, it’s an abbreviation of four adjectives:
To be fully accessible, a website must live up to these four principles. It must be perceivable, operable, understandable, and robust, no matter what physical and mental abilities or disabilities people have.
Commonly to perceive is to see something. But it can refer to any sight humans have. You can also perceive by feel or hear.
The majority of people do perceive websites by sight. We read type, we see color, we spot familiar shapes, and our minds sense structure.
Visual design aims to enhance usability and provide a certain experience by playing around with these primitive elements. However, there are various visual impairments that need to be taken into account when designing for sight.
A person might not be able to differentiate red from green all that well or at all. Therefore color must not be used alone to communicate something. One widespread mistake is to switch between green and red to tell whether a product is in stock or not.
The fact is that everyone’s sight deteriorates as they age. That’s why text needs to be reasonably sized for all users, and site structure must support different text size preferences using responsive web design to our advantage. Text contrast must also be high enough to ease legibility.
At the end of the day, all information must be perceivable without sight too. Fortunately, this is a strength of HTML, because when used correctly, it contains a lot of valuable information and structure that can be presented in multiple ways.
Headings aren’t merely texts of different sizes. They are actual heading elements that form a document outline, and people use them to navigate the page with screen readers. Images have text alternatives. Lists are either unordered or ordered, and their item count is known. Tables consist of headers, columns, and rows. The list goes on.
The beauty of HTML and text content is that it can be communicated to people in many different ways. Assistive technologies do just this and help people perceive websites with different senses.
One very powerful assistive technology is the screen reader. It understands HTML and reads it out loud in a human-understandable way. This enables people to perceive content and structure via hearing.
What if you can’t hear nor see? Screen readers can also output to a braille display. These special machines raise and lower braille dots, which you can then read by feeling the braille characters.
Hearing is also a factor if you provide content in audio form. There needs to be an alternative way to perceive this content. Captions and/or transcriptions are commonly provided in these cases.
The Curb-Cut Effect
Much like curb-cuts help bicyclists, skateboarders, individuals in wheelchairs, and parents with strollers, perceivable websites have benefits for many people. To make the site perceivable means to make the “curb” as non-existent as possible, allowing anyone to use the content.
Digital curb-cutting examples:
- Good contrast helps when you visit a website with your phone in direct sunlight.
- Subtitles help you watch videos when you can’t have sound on.
- Reading an article in reader mode to help focus or saving it for later using special software. This is based on a valid page structure.
- The resizable text allows anyone to resize text out of preference too.
- A white on black contrast mode can also be provided as the dark mode for reading in the dark or just to match the device’s dark theme.
- The curb-cut effect is not limited to perceivable either. Accessibility improvements benefit everyone in unexpected ways. That is not the primary goal of accessibility, but it is a nice side effect.
Perceiving information and structure is one thing. To navigate the website and interact with it is another.
The majority of us got to know the web by using a keyboard and mouse. Mice were and still are one of the main ways of operating links and other interactive elements on the page. It has been replaced partly by touch screens, but essentially we are still pointing at elements on the screen, be it with touch, an optical mouse, a trackball, or a touchpad.
This is not the only way people operate their devices. However, some of us might not have both or even one hand to use the touchpad or keyboard + mouse -combination. A whole world of more ways of operating can be condensed into what WCAG calls “Keyboard Operable.” If designed properly, this means that the site is operable even for users who are able to operate only with a sip-and-puff -device.
Most people operate websites with a keyboard without thinking about it:
- Scrolling the page with up and down arrow keys
- Moving the cursor inside a text field with left and right arrow keys
- Selecting next form element with tab
- Submitting a form with enter
We do this while also clicking links and other elements with our mouse. Removing common keyboard support would be a universal user experience issue. In fact, this is not uncommon. Sometimes websites fail to react to keyboard actions that are in our muscle memory. Or they can prevent scrolling with the arrow keys.
All interactive elements must be keyboard focusable.
Minor usability hiccups aside, many people can’t physically use any pointing device of any kind at all and face terrible user experiences daily. In addition to motor impairments caused by medical conditions such as cerebral palsy and MS, a rather typical case of work-related RSI (Repeated Strain Injury) can also disable one’s pointing ability.
Assistive technologies rely on keyboard support
Making all interactive elements focusable isn’t enough: some interfaces such as tabs are expected to behave in a specific way reacting to different key presses. Focus order needs to be logical too. This is why it’s beneficial to stick to native HTML elements as much as possible. It can be very time-consuming to implement a custom interface correctly.
When you absolutely need a specific user interface design, and it isn’t standard, there are guides on the internet on how to utilize so-called ARIA attributes to implement non-standard user interface widgets. Be careful, though, as these are very easy to misuse and cause even more issues. So use a good source. W3C provides an extensive list of examples here.
Keyboard support also provides the groundwork for many assistive technologies: for example, when there’s an understandable way to open a submenu with the keyboard, it’s also possible to do this with other assistive technologies. Assistive technologies often need a bit more information, such as whether a button is collapsed or expanded.
Whether or not the interface and its state are both perceivable and understandable is evaluated in sections 1. Perceivable, and 3. Understandable in WCAG 2.1.
One critical guideline under operable is 2.4.5 “Multiple Ways.” To meet the guideline, there must be more than one way of locating a page within your website. Ultimately this should protect people from having to use complicated interfaces in order to access the content. It can be overwhelming even to attempt to use a multi-level menu with assistive technologies, even if it’s technically accessible.
It also provides a fallback in a case for whatever reason one way of accessing content completely fails to work. And often, people succeed more easily with a healthy amount of navigation options.
Other than linking between pages in your content and not just in a complicated menu, some common widely accepted ways to locate pages are search functionality, and a traditional sitemap meant for humans (as opposed to an XML sitemap meant for search engines).
In a nutshell: it’s always a good idea to make sure there are at least two accessible ways of reaching the same content.
“Information and the operation of the user interface must be understandable.”
The understandable principle is something designers, and content creators should focus on. It’s also a very challenging subject where there are no clear, correct answers.
Complicated language is likely the most common violator on websites with much information. There isn’t much you can do other than raise awareness within your content team. It can be tricky to simplify content because sometimes the information itself is very complicated, but we should put in a real effort. One of the easiest ways is to keep sentences short. Say one thing in one sentence.
Traditionally understandability of user interfaces lives under user experience design. For example, Nielsen Norman Group has done a remarkable amount of research on user experience for years. They provide articles where they have researched common user interface issues and point out problems in different solutions. So this part of accessibility is already well known to designers in a way.
Available research articles aside, ultimately, it comes down to whether people using a particular service understand its content and user interface or not. Fortunately, this is something UX designers are good at figuring out when they’re given resources to facilitate user testing and research.
Something else to keep in mind about understandability from an accessibility point of view is inclusive design. When designing services and user interfaces, we need to include different kinds of people. A design that works for seeing young people familiar with computers using a mouse and/or touch screen may not be good overall.
By including all kinds of people in the design process as early as possible, we decrease the possibility of missing valuable information.
There are still a few common relatively straight forward guidelines under understandability. You can look out for insufficient form labeling and instructions, or changes of context not initiated by the user. And perhaps one of the most impactful guidelines to follow – especially on a multilingual website – is providing the language of the page programmatically. For assistive technologies and translation plugins, it is vital to know the source language with certainty.
Combinations of different types of browsers and operating systems behave differently, causing bugs and therefore struggle for the developers.
Robust isn’t all that different from what we’re used to already. The difference is that it extends awareness to assistive technologies and any other machine that deals with semantics.
Anything from duplicate IDs, too many HTML elements, and invalid attributes could trip assistive technologies. They may simply stop working if a web page’s HTML is too broken.
As said earlier in this article, it’s vital to use the ARIA role, state, and properties when you implement custom user interface widgets. It’s also crucial to use them correctly. Incorrect markup may work in some cases, but it isn’t robust and could fail in another scenario.
Out of all the POUR principles, robust is likely the most machine testable. HTML validators have been available for years. There are also many automatic accessibility tools such as aXe and Wave. Among other WCAG guidelines, these test ARIA validity and look for missing labels. Of course, machines can’t (yet) judge whether a specific element should’ve been used as they don’t understand semantics. They can only check the validity of what they perceive directly.
From POUR concept to more detailed guidelines
Once you feel comfortable with POUR as a concept, you can start reading WCAG guidelines one by one; you find them here.
It’s a long list, but it’s relieving to know that not all guidelines are relevant all the time or for all elements. Also, you can focus on just a few in the beginning. Read about the techniques they require (How to meet guideline) and about their underlying issues (Understanding guideline).
Here are some recommended guidelines to focus on first:
- 1.1.1 Non-text Content
- 1.3.1 Info and Relationships
- 1.4.3 Contrast (Minimum)
- 2.1.1 Keyboard
- 2.4.6 Headings and Labels
- 2.4.7 Focus Visible
- 3.2.1 On Focus
- 4.1.2 Name, Role, Value
Understanding these guidelines is a good start. Following them prevents many possible accessibility issues. That’s the essential bit. Remembering that form should follow function is an excellent design guideline also for this topic.
We at Wunder work hard to make sure the sites we design are accessible, visually pleasing, and modern. We are more than glad to help you make your digital services accessible with style.