Building an accessible product - part 1

In the previous post we covered a few fundamental concepts:

• accessibility means making services and information easy to use for people with perceptual or cognitive difficulties, so that no one is excluded;
• these people are a considerable number;
• vision problems often depend on age, but they are not the only ones;
• we have international standards that tell us how to build accessible digital products;
• we can run quick, intuitive tests, manual or automated, to check that we are meeting these standards.

Before going further, it's important to clarify what this term means, because you'll come across it very often: a11y is short for accessibility, since there are 11 letters between the first and the last letter, and it's pronounced "ally".

But it's not just an abbreviation: it's a worldwide movement that goes far beyond making web products accessible and focuses on making the entire computer system, both hardware and software, accessible to people with disabilities.

Making a digital product accessible is a challenge that spans many of its aspects. We want it to be compatible with specific:

1. conditions of use (contrast and readability, zoom);
2. modes of use (keyboard navigation);
3. technologies (screen readers);
4. preferences (prefers-reduced-motion, custom styles).

If this is our first time tackling this work, a few starting questions can be very helpful to set our direction:

• Can you do everything with the keyboard as well as with the mouse?
• Is the screen reader providing relevant information?
• What happens if I zoom to 200%?
• Is the text readable enough?

They are technical standards, for both development and design, that make a product accessible.

They are organized into principles and guidelines that provide a frame of reference and the overall goals for understanding the success criteria and applying the techniques effectively. The success criteria, specific to each guideline, define the possible conformance levels (A, AA, AAA).

Finally, they offer sufficient and advisory techniques along with documentation for each guideline and each success criterion.

We can use numeric, and therefore objective, values that tell us whether text has enough contrast and is readable against its background. This contrast ratio depends on both the color and the size of the text. There are browser extensions and design tool plugins that help check this ratio, such as Colour Contrast Checker.

A problematic but very common case is text over images, where you need to make sure the minimum contrast is guaranteed. As highlighted by this research by Nielsen Norman Group, there are a few techniques we can use to achieve this:

1. use images with dark tones;
2. set a dark linear gradient in front of the image and behind the text block, using CSS with a before pseudo-element;
3. set a radial gradient behind the text block, with a before pseudo-element.

Keyboard accessibility is one of the most important aspects, because many users with motor and visual impairments rely on it. Some people have involuntary movements that prevent precise mouse control, others have limited use of their hands. Some have no hands at all.

Blind and visually impaired people use the keyboard together with a screen reader. In addition, some users without disabilities prefer the keyboard and find it more efficient and practical for interacting with the product.

We can try this mode by pressing the TAB key, which takes us to the first interactive element. We are now in the focus state. Pressing TAB again moves to the next interactive element. If it's a button or a link we can press ENTER, while if it's an input we can fill it in.

This attribute controls the order in which interactive elements are reached when navigating with the keyboard. Setting it on an element lets you override the normal top-down order.

One important thing to keep in mind is that setting this attribute on an element that isn't natively accessible, such as a div or a span, makes it interactive, so it should be avoided. As we'll see later when discussing HTML tag semantics, using the right tags is important to avoid accessibility issues.

It quickly becomes clear that for keyboard navigation it's essential to provide a visual indication of which element currently has focus. This can cause problems, because the style is also applied when an element is clicked with the mouse. Removing the focus style solves this problem but makes the product inaccessible, so what can we do?

A new state for interactive elements has recently been implemented: focus-visible.

Applying a style only to this state enables it only when focus needs to be visible, which is exactly the case with keyboard navigation. On the related Mozilla Developer Network page you'll find details on how it works. Keep in mind that this new state currently has 73% browser support, so we recommend using the official polyfill to cover all other browsers.

If you've tried navigating a website with the keyboard, you'll have noticed that every time you change page you have to tab through all the interactive elements before reaching the site's content. Skiplinks exist to spare you this tedium: they are anchors that let you jump straight to the content, and they should be the first interactive element activated from the keyboard.

To make these links visible only when using the keyboard and not the mouse, we can use this CSS:

And we'll get this result:

Imagine building a UI just for a screen reader. All you'd need to do is describe the page structure, much like the DOM, but with fewer nodes and less information, since much of it relates to visual appearance.

That's exactly what the browser does: it takes the DOM and modifies it to make it usable by the screen reader, following these steps:

1. When the site opens, the browser exposes a semantic version of its UI to the assistive technology via API.
2. The screen reader takes what it receives via API and creates its own presentation UI, made of a spoken representation.
3. The user is offered a way to interact, for example a hook that simulates a tap or click.
4. The screen reader sends the action to the site, which interprets it in the original UI.

So HTML tag semantics are essential for building the accessibility tree correctly, because when you use the right tag, the accessibility tree creates the corresponding interface for interacting with it, for example with buttons and links.

Another important aspect is heading order (H1, H2, H3 tags, etc.). Screen readers and keyboard navigation rely on the content's heading structure to offer a navigation path through the page, so it's a requirement to structure headings in descending order.

That wraps up part one. Next week we'll continue by focusing on aria-attributes and going into detail on the accessibility of interactive elements, two topics so big and complex that they deserve a post of their own.

Cover image: Building Technology Heritage Library (BTHL).