Article

Accessibility in web development: 8 mistakes to avoid (2/3)

22/07/2025

After looking at common web accessibility mistakes in Part 1, this sequel focuses on key elements for making an interface usable by all.

We'll start with keyboard navigation, useful for those who can't use a mouse. Then we'll explain ARIA attributes and roles, which enrich semantics and facilitate reading by assistive technologies.

Finally, we'll present tools that help developers create accessible applications, detecting and correcting errors as they develop.

6. Keyboard keyboard

When developing an interface, developers are guided by one essential rule: the use of a mouse is not mandatory. To guarantee web accessibility, all functionalities must remain usable by those who can't or don't want to use a mouse.

The user moves between elements with the Tab key, then interacts with them via other keys such as Arrow, Enter, Space or Escape.

Assistive technologies read the active element. However, for those who don't, a visual indicator needs to be added to the active element so that the user can locate its navigation position. This is achieved by using the CSS state `:focus-visible`, which is activated when an element receives focus from keyboard navigation.

Note: We generally use the same visual representation as the `:hover` state to represent `:focus-visible`.

7. Additional information : ARIA and role

ARIA (Accessible Rich Internet Application) represents the set of HTML attributes that can be used to provide additional information on tags, enabling the user to specify content, usage or status. These attributes enable assistive technologies to better render the information and interactions available to the user.

They are generally associated with the 'role' attribute, which we've already seen with `role=button`. Many roles exist, each linked to well-defined ARIA attributes.

These attributes do not replace the appropriate semantic tag. They complete the tag when necessary or when no tag corresponds to the need.

There are many roles and ARIAs that can be used, but here is a list of examples:

`role="tooltip"`: Represents additional information text that appears dynamically when an element receives the focus or hover state. They are linked via the `id` and `aria-describedby` attributes.
role="switch"` : Semantic transformation of the checkbox to an activated/deactivated state
aria-hidden`: Hides html tag content for assistive technologies
`aria-expanded`: Describes the visible or non-visible state of another element. They are linked via `id` attributes `aria-controls`.
`aria-current`: Declares an element as the "active" one in a list. For example `aria-current="page"` defines the link of the current page in a list of links (pagination, breadcrumb, ...).

Depending on their nature, ARIAs must be dynamically updated using javascript. It is possible to use Angular'sattribute binding, for example `[attr.aria-expanded]="isExpanded"`.

The aria-label

Let's take a closer look at the `aria-label`, which is the most widely used (if not the most important) ARIA property. It gives meaning to the entire block to which it is assigned.

Let's take a list of items consisting of an image, a title and a description. Each item is a link to a detail page. Assistive technologies read the entire content of the card, often in the form of messy text, to indicate what the link contains. To facilitate navigation, we can use the `aria-label property with the article title. This allows the user to have a clear summary of the link, while still being able to access the details if they wish.

				
					<ul>
  @for (article of articles; track article.id) {
  <li>
    <a
      [routerLink]="[article.id]"
      [attr.aria-label]="article.title"
    >
      <article>
        <img [src]="article.src" [alt]="article.accs" />
        <h3>{{article.title}}</h3>
        <p>{{article.description}}</p>
      </article>
    </a>
  </li>
  }
</ul>

Similarly, we could use `aria-labelledby`, which has the same utility but uses the reference to another element on the page via its id :

				
					<ul>
  @for (article of articles; track article.id) {
  <li>
    <a
      [routerLink]="[article.id]"
      [attr.aria-labelledby]="article.uniqueKey"
    >
      <article>
        <img [src]="article.src" [alt]="article.accs" />
        <h3 [attr.id]="article.uniqueKey">{{article.title}}</h3>
        <p>{{article.description}}</p>
      </article>
    </a>
  </li>
  }
</ul>

8. Use the right tools

There are many other rules relating to web accessibility. Today, there are many tools at our disposal to help us develop in an accessible way while avoiding possible oversights and errors.

Firstly, through IDEs, the software that enables programmers to develop applications. They are highly configurable and increasingly integrate extensions to facilitate the developer experience. The developer console integrated into browsers also includes a section providing a better representation of the accessibility (via a dedicated tab) of the transcription made of our html code.

Secondly, through the use of accessibility linters. A linter is a tool integrated into a development project to define development rules. They help to improve code quality and consistency between different team members. There is a wide variety of accessibility linter available today, either directly integrated into more global linters (as in the case of angular eslint, for example), or more specialized (a11y, html-validate, etc.). The choice is yours.

Implementing different accessibility criteria in the various automated tests (unit or e2e) or functional tests via defined standards is also a good way of guaranteeing the validity of an application's code and various functionalities.

This is the end of the second part, and the rest, devoted to a case study on the web accessibility of a drop-down menu, will be available shortly.