Breaking down barriers: How to make digital services accessible to everyone

Since the EU brought in its European Accessibility Act (EAA) in June, accessibility has become a hot topic. For Swiss companies, the EAA—like the GDPR—only applies if they offer services within the EU. However, there are some aspects that they too need to consider, which we will touch on later. The EAA has two key impacts: Firstly, some sectors, including financial institutions, are obliged to make newly created websites accessible; and secondly, projects that have neglected accessibility for years now need to be made fit for the future as envisaged by the EU.
The aim of the act is to ensure that users with visual impairments or motor disabilities, and also older people, can use digital services without encountering any barriers. The question of how this objective is meant to be achieved has largely been left open. In web development, this requirement is referred to as “accessibility”. As part of a major initiative, ti&m has also added an “accessibility” feature to its mobile and e-banking platform, ti&m Banking.
 

The largest group affected is users with partial or complete color blindness. This affects 8 percent of men and 0.5 percent of women in Europe. The second largest group is people with severe visual impairments, who need to have the option to display content in a significantly enlarged format. When it comes to ensuring accessibility, designers therefore have a particularly important role to play. They must make sure their choice of color scheme works even for colorblind people. A minimum level of contrast is required between text and background, and all text must be easy to read even in dark mode or ultra-high contrast mode.

Blind people cannot use a mouse because they are unable to see the cursor, so they need to be able to navigate through a website using only a keyboard. There are also users who cannot use a mouse for other reasons, such as physical limitations, and rely on special input devices instead. Sighted users can navigate through a website two-dimensionally using their mouse cursor. For blind people, however, a website needs to have a linear or hierarchical tree-like structure. This is why full keyboard operability is crucial, and whether accessibility was a requirement right from the outset or not can make a big difference in this respect.

User navigation via a keyboard must be planned into the design in the same way as user navigation via a mouse. The keyboard focus must be transferred smoothly to any pop-ups and dialogs and back again when a dialog is closed.

Sometimes it may be that a feature that has been developed for a customer with a designer and can be used intuitively by sighted users cannot be made accessible. In this case, the entire concept has to be revised and re-implemented in coordination with the customer. By far the most complex part of making a website accessible is making sure it can support screen readers. Screen readers enable blind people to use a computer and they run within the operating system, not directly in the browser. macOS and iOS already have an established built-in screen reader called VoiceOver. In Switzerland, the JAWS and NVDA software for Windows are also very popular.

Checking whether a website or component is accessible requires special tools and experience. For normal users, the accessible features are hidden. The only way to ensure that an application can actually be navigated by blind people is by testing the website and processes with a screen reader. This means that not only developers have to be able to use a screen reader, but product owners and UX designers, too.
 

Planning
The first obstacle arises in the planning stage. Ensuring accessibility is a complex task, so the team has to break it down into smaller chunks. But how? Accessibility is measured based on compliance with WCAG (Web Content Accessibility Guidelines) rules. These include aspects such as compliance with contrast levels, the scalability of text, and the use of alt text attributes for all images. However, dividing up user stories according to WCAG rules would be disastrous. This approach does not work in practice, because each developer would have to change a large part of the code base for practically every user story. Division based on the structure of a web application would be a more suitable solution. Modern UIs are based on a hierarchical structure of components. Each individual component, from a simple button to a complex landing page, can be customized in a step-by-step process: by focusing first on the atomic components such as buttons or input fields, and then on the compositions, where several components are put together to form a new component. In addition, various processes and procedures that have nothing to do with UI components also have to be adapted.

It is easy to forget that it is not just the web application that needs to be accessible—all downloadable and linked PDFs do too. These often come from third-party providers, and they also need to be included in the planning.
 

Implementation 
During implementation, it is important for developers to be able to put themselves in the position of impaired users. They often have to improvise, because the documentation from the various experts—such as the WAI ARIA Working Group, which is responsible for defining accessible web standards—is often incomplete and sometimes contradictory. The Swiss Accessibility Developer Guide, which is relevant for us, is also no longer proactively maintained and revisions are only published sporadically.  If you use a fully accessible UI library from the outset, you can save yourself several months of work. Otherwise, you have no choice but to make the entire UI library accessible first. The WAI ARIA specification prohibits certain HTML structures that are often used by designers and can easily be displayed by a browser—such as nested interactive elements, as often found in tile-based designs. A tile is linked, but also contains a second link or a menu button. Often, it is therefore not only necessary to adapt the code, but also to make adjustments to the design system. It is important to pay particular attention to focus control. If a user interaction opens a pop-up, the keyboard focus has to be moved to that pop-up. Then when the pop-up is closed, the keyboard focus has to be returned to a logical location. Ideally, this focus control would be defined during the first design phase.

Micro-frontends. or-more specifically- Web Components technology, pose a particular challenge. These make components logically independent from one another, which simplifies collaboration between different teams, but can be problematic if components logically belong together. ARIA tags do not work beyond the shadow DOM limits of Web Components. The World Wide Web Consortium (W3C) is aware of this problem and has been working on a solution, the Accessibility Object Model, since 2017. However, this solution is still pending.
When developing UI components with React, Storybook is generally used to display the components in a design system. There is a plug-in for Storybook that tests components in terms of their accessibility. This plug-in is an indispensable tool.
 

Validation
An accessible site still looks the same afterwards as it did before. At first glance, the only noticeable differences are small changes to certain details-for example, all buttons will now be at least 24 x 24 pixels in size. Accessible technology is invisible to non–expert users.
Accessibility can only be tested to a limited extent with a browser. However, there are some tests you can use to quickly check how far you have got in terms of making your website accessible. One initial test you can do is to try using the website without a mouse, relying only on a keyboard. If you can navigate through all user flows, you are well on your way. You should also see the skip links; this is a UI element that allow users to skip the title elements and is only visible with keyboard focus. Another test involves setting the default font size to the maximum level in the browser settings and checking that this does not break the layout. The browser's developer tools (e.g. Lighthouse in Chrome) also include an automated test that checks how well a website follows a set of accessibility rules. Achieving a good score is important, but it does not necessarily mean that the site is accessible. Manual testing with a screen reader is needed to confirm this. You have to test your website accessibility on both desktop and mobile versions. Many web developers use Macs, and therefore use VoiceOver with Safari. In our experience, Safari is the browser that works best with VoiceOver. VoiceOver is also available on iOS, of course, but it works differently there than on macOS. iPhones and iPads are now the most popular systems among visually impaired people for private use.
The JAWS and NVDA screen readers are available for Windows. JAWS is expensive—there is a discount available for the visually impaired, but it is costly for developers to buy. Alternatively, we recommend using the free screen reader NVDA. On a Mac, you can run this in a Windows VM, for example using VMware Fusion. This also includes a 30-day Windows license.
Once everything has been implemented and tested internally, the application still needs to be checked by experts. In regard to this, we have enjoyed success working with Access for all, whose reports are well written and informative. They help developers to quickly rectify any problems found and to avoid these errors in future projects.