How to understand, practice, and benefit from web accessibility

At Wunder, we claim that accessibility is a human right and every single website or app, intranet, or e-commerce solution should be consumable to any user. Yes, it might feel overwhelming at first, but once you understand the reasons, it all, even the huge documents, becomes clear. We have found or way how to understand, practice, and benefit from web accessibility, so let us reveal how we are building a world where digital belongs to everyone.

Why does accessibility matter?

Many people might think that web accessibility is a lot of effort for just 1 % of the population. Or if you don’t have any users with disabilities, you can just ignore it. In reality, accessibility is much more than making the internet work with screen readers or other assistive technology. It’s about giving everyone equal access to the digital services we’re building.

In fact, everyone benefits from accessible web services since they are usually easier to use and understand. Who would not want that? Plus accessibility is actually good for businesses too if aiming to reach as many users as possible.

And if you still want some stats:

• More than a billion people in the world live with a disability. That’s 15% of the whole population. (Source: World report on disability, WHO, 2011opens-in-a-new-tab)
• In Finland, over one million people need accessible services. That’s almost one in every five people. (Source: Kenelle saavutettavuus on tärkeää? AVIopens-in-a-new-tab)

The whole point of accessibility is to make sure everyone has an equal opportunity to participate in society. Accessibility is thus a basic human right. We as creators, owners, and maintainers of web services have a huge opportunity – and responsibility – in this respect.

Creating services for the real world – and preferably together with the people who actually use them – is exactly what we do at Wunder. We strongly believe that no two people are alike, we all have our limitations, or just days when it’s simply too difficult to concentrate on reading complex text. Therefore we do not design for people with specific disabilities, we design for all people.

How to practice web accessibility?

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 and its latest release version WCAG 2.1opens-in-a-new-tab.

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 EU accessibility legislation that is now in effect in its member countries leans on WCAG.

As the list of guidelines and criteria is exhaustingly long, we have found the POUR principles very beneficial in our daily work. It’s much easier to keep these four core principles in mind rather than the 80+ guidelines with technical criteria. Instead of remembering hundreds of checkboxes to tick, you try to understand the reasoning that results in an accessible web service. We are happy to share our condensed understanding of POUR.

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:

• perceivable
• operable
• understandable
• robust

To be truly 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. Let’s get to know each of them one by one.

1. Perceivable

Commonly to perceive is to see something. But it can refer to any sight humans have. One can also perceive by feel or hearing.

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.

Also, 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 its advantage. Text contrast must also be high enough to ease legibility. On the other hand, some people will have an easier time with a darker background with not too bright text on top. Luckily, both ways are possible through the built-in light and dark mode switch in modern devices – as long as one’s web service supports them.

At the end of the day, all information must be perceivable without sight too. Fortunately, this is a strength of web technology, because when used correctly, it contains a lot of valuable information and structure that can be presented in multiple ways. For example, headings aren’t merely pieces of text of different sizes. They have a significant role in forming a document outline – people use them to navigate the page with screen readers, they benefit the web search results, etc. 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 and on.

The beauty of web documents is that they can be communicated to people in many different ways. Assistive technologies make heavy use of the visually hidden information about elements in web documents and help people perceive the structure of a website with a variety of senses.

One very powerful assistive technology is the screen reader. It understands HTML – the markup language that web documents consist of – and reads it out loud in a human-understandable way. This enables people to perceive content and structure via hearing.

What if one can’t hear or see? Screen readers can also output to a braille display. These special machines raise and lower braille dots, which one can then read by feeling the braille characters.

Hearing is also a factor if one provides 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-cutsopens-in-a-new-tab 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 everyone to use the content more easily.

Digital curb-cutting examples:

• Good contrast helps when visiting a website from the phone in direct sunlight.
• Subtitles help when watching videos with no sound on.
• Reading an article in reader mode help focus or to save 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.

2. Operable

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. Some people might have challenges using one or both of their hands to operate these common physical interfaces. For this purpose, there is a whole WCAG guideline called “Keyboard Operable”. Although the word keyboard is selling it short since the guideline ensures that one doesn’t even need an actual keyboard to interact with a website. Instead, if designed properly, a “keyboard operable” site can be used by people who are able to interact only with, for example, a sip-and-puff -deviceopens-in-a-new-tab.

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 the 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 a rare occurrence. Sometimes websites fail to react to keyboard actions that are in our muscle memory. Or they can prevent scrolling with the arrow keys. This creates inconvenience for people used to common keyboard interactions.

Minor convenience hiccups aside, many people can’t physically use any kind of pointing device 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.

This is why all interactive elements must be keyboard-focusable. In some browsers, pressing the tab key doesn’t only select the next form element; it also selects the next link, button, or another interactive element. It’s very common to run into interactive elements such as dropdowns or filters that aren’t keyboard-focusable and therefore impossible to operate with a keyboard – or other devices relying on “keyboard operability” as mentioned earlier.

Read more about digital assistive technologies

Multiple Ways

One critical guideline under operable is 2.4.5 “Multiple Ways.” To meet the guidelines, 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 solution in case one way of accessing content fails to work for someone. And often, people succeed more easily with a healthy amount of navigation options so they can use their go-to method to find what they are looking for.

Other than smart 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 (not to be confused with a technical sitemap meant for search engine optimization).

In a nutshell: it’s always a good idea to make sure there are at least two accessible ways of reaching the same content.

3. Understandable

The understandable principle is something designers, and content creators should pay a lot of attention to. It’s also a very challenging subject where there are no clear or correct answers. Out of all the four principles, it requires the most embracing of its spirit as it doesn’t come with as many clear criteria.

Complicated language is likely the most common violator on websites with a lot of information. There isn’t much we can do in advance other than raise awareness within our content teams to produce easy-to-understand text. 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 best ways is to keep sentences short. Say one thing in one sentence.

Beyond understandable content, there also needs to be an understandable user interface (UI). Traditionally understandable UIs are considered part of user experience design, but they are also an accessibility concern. Nielsen Norman Groupopens-in-a-new-tab has done a remarkable amount of research on user experience which helps us know what is and isn’t understandable in the context of UIs.

Unfortunately, there is never going to be a readily available study for each use case. Instead, insight needs to be applied and new user testing is also recommended when creating unique UIs. For our all good, this is something UX designers excel at facilitating.

Another way of thinking about understandability from both a UX design and accessibility point of view is the concept of inclusive design. When designing services and user interfaces, we need to include different kinds of people. This broadens our knowledge of the ways how people interact with digital services. By definition, this should include not only accessibility needs but also somewhat forgotten user groups such as people who rarely use technology.

4. Robust

Robustness is all about the fragility of web technology and technical accessibility. Combinations of various browsers and operating systems behave differently. Websites breaking with some of these combinations is nothing new in the history of web development. However, from the accessibility point of view, it’s important to realize that screen readers and other assistive technologies can also behave in unexpected ways.

In practice, robustness as a principle is about making web documents by the book. This is the only way to decrease the likelihood of unexpected behavior with some hardware and software combinations. There are no guarantees, because of software bugs – often found in screen readers – that cause issues even though the web document has been implemented correctly. In those situations, we are easily tempted to work around these bugs. Beware that this can cause a “short blanket dilemma” where changing the document to avoid a software bug can introduce more accessibility issues. Sometimes all we can do is stand behind the fact that the document is robust and expect a software fix from its vendor.

In technical accessibility, we sometimes need to utilize Accessible Rich Internet Application (ARIA)opens-in-a-new-tab properties when implementing custom user interface widgets. It’s crucial that they are used correctly because even slightly incorrect use of ARIA properties skyrockets the risk of inaccessibility.

Out of all the POUR principles, robust is likely the most machine testable. HTML validators have been available for years. There are also many automated accessibility testing tools such as Siteimprove, aXe, and WAVE. These tools are able to test ARIA validity among other machine testable WCAG criteria. Of course, machines can’t (yet) judge whether a specific solution should’ve been used as they don’t understand semantics and the bigger picture of usability the way people do. There have been attempts to create smarter tests, but for the most part, these tools can only check if certain easy-to-define rules are followed which is why technical correctness or robustness is an especially suitable use case for them.

The rabbit hole

Once you have familiarized yourself with POUR, you can go multiple directions from there in order to learn more about how these principles are carried out in practice. We have various accessibility articles - such as Accessibility terminology, Accessible UIs, Digital assistive technologies and Accessibility testing - full of advanced information and links to useful external resources that can take you down the rabbit hole.

At Wunder, we do not look at accessibility as a separate optional concern. Instead, we keep these principles in mind and work hard to make sure that every single site we design is accessible, visually pleasing, and modern.