Web accessibility: how to develop inclusive user interfaces

Inclusivity is a hot topic in today's society and the world of software development makes no exception. Building inclusive and universally accessible software products means broadening the user base and allowing more people to benefit from the same service equally and democratically, resulting in both ethical and business benefits.

In addition, recent regulations such as the European standard EN 301 549 have begun to define legal obligations, imposing minimum accessibility standards on digital content developed by private companies. But that's not all: the United Nations' Agenda 2030 itself speaks about accessibility. In fact, one of its goals is to Significantly increase access to information and communications technology [...] to provide universal and affordable access to the Internet.

Therefore, it is clear that nowadays dealing with web accessibility is a necessity for companies, not only due to sensitivity to consumers but also out of legislative compliance and social commitment.

What does "Web Accessibility" mean?

Web Accessibility refers to the ability of a site, application, or digital interface to be used effectively by all users, regardless of their physical condition and any disabilities that might affect navigation.

The issue of web accessibility is of very wide impact: the WHO estimates that in 2022 more than 1 billion people (about 15% of the world's population) suffer from some form of disability. This includes both visually difficult conditions (blindness or low vision) and physically difficult conditions (paralysis or physical damage that might prevent the use of a mouse or keyboard), but also auditory, cognitive, or neurological problems.

Achieving an accessible and inclusive Web is one of the goals of the W3C, the global consortium that oversees the organization and standardization of the Web. In this regard, W3C has produced the Web Content Accessibility Guidelines (WCAG): a collection of accessibility guidelines that serve as a reference point in the design of Web interfaces, as well as the basis for all relevant legislation.

We now collect some guidelines to follow to improve the accessibility of our systems, according to WCAG 2.x.

Visual accessibility: fonts and colors

Starting with the basics: a website must always be well‑readable. This means maintaining a font size that is comfortable to the eye (at least 16px) and carefully selecting the type of font (sans‑serif fonts are generally considered more accessible). Some fonts have been designed specifically for accessibility purposes: for example, Open‑Dyslexic, an open-source font tailored for users with dyslexia.

On top of that, it is essential to make sure that the page remains readable in case the user redefines the zoom. Very often, if the architecture of a Web site has not been properly designed, a very high zoom (e.g., over 150%) can result in text spilling out of the screen, with severe impacts on the usability of the website.

The choice of colors is critical. WCAG 2.x sets a contrast standard to guide the selection of the color palette, imposing a minimum contrast level of 4.5:1 (and optimum of 7:1) between the main text color and the background color. It is also good to avoid certain color combinations (in particular green‑red), which may be inaccessible to those with color blindness. The same goes for multicolored, patterned, and picture backgrounds, which can generally hinder reading.

Finally, it is important to make sure that regardless of the chosen colors, the outline of visual elements (i.e., the colored border that appears around inputs and buttons) is always clearly visible. The outline is critically important for the purpose of accessible navigation because it allows users to locate at a glance the last active interacting element.

Navigation accessibility

Not all people navigate the web in the same way. Particularly severe or disabling physical disabilities may in fact preclude the use of a mouse, limiting the user to keyboard navigation. Similarly, visual problems or blindness may lead users to equip themselves with screen readers, software that scans Internet pages and reads text content aloud, acting as a support or substitute for the visual medium. In such cases, navigation is performed through key combinations, which allow users to move nimbly through the content of interest on a page.

With these scenarios in mind, it is easy to see how taking care of keyboard navigation is a requirement of paramount importance in building inclusive web interfaces. Therefore, it is useful to set up a top‑down flow of page content, enabling users to move between elements on the page and interact with them as they would with a mouse.

Specifically, the user should always be able to move sequentially between interactive elements on the page (forms, buttons, etc.) with the Tab (forward) and Shift+Tab (backward) keys. It is therefore important to pay attention to the focus order, that is, the consecutive order in which these elements will receive focus from the user. Similarly, complex components, such as tabs and radio button groups, should always be navigable internally by arrows, while links and buttons should be designed to be pressed with Enter or Space. Widgets or blocking modals, on the other hand, should always be able to be closed using the Esc key. It is also important to correctly position headings (e.g., h1, h2, etc.) so that the user can navigate between them (e.g., via H).

Once a navigation flow has been set up, it is a good idea to conduct manual tests by simulating user behavior, particularly by verifying that there are no elements that block movement and prevent removing focus (focus trap).

Code accessibility: HTML and ARIA

When developing an accessible interface, one focus to concentrate on is the code itself. The more semantically expressive we can be in our writing, the more the browser will be able to interpret what we write and readjust the user experience accordingly, such as by prioritizing certain content or providing additional information when reading via screen reader.

The first step toward more accessible code is the use of semantic HTML tags. Although HTML is the skeleton of every web page, in fact, its use is often limited to generic tags such as <div> and <span> which, although effective, do not provide information about our intent in development. Using semantic tags such as <header>, <footer>, <main>, or <nav>, on the other hand, allows browsers to understand the semantics of elements and modify the user experience accordingly.

Where HTML is not sufficient, you can increase the expressiveness of your code with the help of ARIA. ARIA (Accessible Rich Internet Applications) is a technology suite published by W3C, which provides a collection of accessibility‑specific HTML roles and attributes, along with a standard for using them.
ARIA attributes (such as aria‑label, aria‑checked, aria‑disabled, etc.) enable HTML tags to be detailed with additional information that cannot be expressed through the base language (e.g., marking a <div> with aria‑disabled=true to signal to the browser that it is in a disabled state).
Roles (such as banners, feeds, tabs, etc.), on the other hand, allow us to define the explicit intent of our elements (e.g., by marking a <div> with role=alert to make explicit its function of alerting the user or a <p> with role=presentation to indicate that it is text for aesthetic purposes and therefore ignorable by screen readers).

Conclusion

Developing accessible Web interfaces is not easy, but it is a goal that should be striving toward. Besides being a legal requirement for many companies, in fact, web accessibility enables us to achieve a better digital world in which we can navigate and access online content without barriers or discrimination.

This article was written by Andrea Mafessoni, Full‑Stack Engineer Expert at Mia‑Platform.