AAA – Accessibility in Angular with the help of AI

The Premise

In the following, I’d like to report on a client project in which we are developing a Single Page Application using Angular. Since the start of the project 15 months ago, we have been deliberately using Artificial Intelligence (AI) to support our developers in their work. All reusable user interface (UI) components are stored in a central directory and integrated into individual views from there. To keep migration efforts low and avoid dependencies on external projects, we develop these components entirely in Angular. This means we have complete control over the design and behavior of each individual component – and also over their accessibility.

Developer Experience

The developer experience with AI in terms of accessibility depends heavily on the type of UI component. We have divided them into three categories:

‘The Good’ are simple, almost atomic HTML elements we all know from any website: elements like checkboxes, dropdowns, and input fields. In our project, these components are minimally styled, and their behavior remains largely unchanged. Accessibility for such components is well documented and defined in web accessibility standards like the Web Content Accessibility Guidelines (WCAG).

‘The Bad’ are complex components whose behavior is shaped by more intensive use of JavaScript. Examples include a date range picker and a dropdown component with search and creation functions (combobox). These components are closely tailored to specific project use cases. Ensuring accessibility here is often a demanding task.

‘The Ugly’ are modified ‘Good’ components that are somewhat repurposed: components that are essentially simple HTML input elements “under the hood,” but whose appearance has been drastically altered using CSS. Examples in our case include a theme switcher and an expandable element.

Quick Excursus: What Are ARIA Attributes?

Before we look at the examples in detail, a quick glance at ARIA: ARIA stands for Accessible Rich Internet Applications. It’s a set of special attributes that can be added to HTML elements to improve accessibility, particularly in dynamic web applications. When the native semantics of HTML are not sufficient to describe the role, state, or properties of a complex UI component, ARIA helps fill that gap. It provides assistive technologies, like screen readers, with additional information so users can understand what an element is and how to interact with it. In the following, we’ll encounter several of these attributes:

• aria-label: Gives an element an accessible name (a label), used when no visible <label> is present or sufficient (e.g., for a button showing only an icon). Screen readers will read this name instead of the element’s content.
• aria-describedby: Refers to the ID of another element that provides additional description or instructions. Screen readers read this description in context.
• aria-checked: Indicates the state of a checkable element (like a checkbox or radio button), e.g., “true”, “false”, or “mixed”. Often redundant for native HTML checkboxes.
• aria-expanded: Signals whether an element that toggles visibility (like an accordion or menu) is currently expanded (“true”) or collapsed (“false”).
• aria-controls: Specifies the ID of the element(s) controlled by the current element. Helps screen readers understand which area is affected.
• aria-hidden: Hides an element and all its children from assistive technologies (“true”). The element remains visually visible (unless hidden via CSS) but is ignored by screen readers. Useful for purely decorative elements or those irrelevant to screen reader users.

With this knowledge, we can better understand why and how the AI attempted to use these attributes in our components.

‘The Good’ – Simple Components in the AI Check

Let’s begin with the components where AI was able to play a helpful role.

<select> (Dropdown)

What it is: A select element (also called a dropdown) allows users to choose from multiple options after a click or keyboard interaction.
What needs to be done: From a developer’s perspective, no special effort is needed to make a dropdown keyboard-navigable — the browser handles that. For assistive technologies like screen readers, it’s crucial that the select element is properly linked to its descriptive label using the id of the select and the for attribute of the label.
What the AI did with it: The AI added exactly what was needed for basic accessibility:

<label + for="nato"> Select a Nato phonetic Letter </label> <select + id="nato"> <option value="None" selected disabled>Select a letter</option> <option value="A">Alpha</option> <option value="B">Bravo</option> <option value="C">Charlie</option></select>

However, one AI tended to over-implement, adding unnecessary aria-label attributes, which don’t provide additional value when a proper <label> is already associated — in fact, it could override the label.

<input> (Text Input Field)

What it is: A basic text input field.
What needs to be done: As with the select element, a connection between the label and the input using for and id is required. Additionally, a hint (e.g., usage examples or format instructions) is often helpful and should be semantically linked to the input using aria-describedby.
What the AI did with it: The AI correctly proposed adding a hint (a <div> with an ID) and linked both the label (via for/id) and the hint (via aria-describedby) to the input field:

<label + for="best-nato-letter"> The best NATO letter is: </label> <input type="text" + id="best-nato-letter" + aria-describedby="best-nato-letter-hint"/> +<div class="hint" + id="best-nato-letter-hint"> + Example: Alpha, Bravo, Charlie+</div>

<input type=checkbox> (Checkbox)

What it is: A box that can be checked or unchecked using a mouse or keyboard.
What needs to be done: As with input and select elements, the key is linking the label and the input using for and id.
What the AI did with it: The AI correctly recognized the need for the for attribute:

<input type="checkbox" + id="alphaCheckbox"/> <label + for="alphaCheckbox"> Alpha </label>

However, most AIs also wanted to add an aria-checked attribute. This attribute is primarily intended for custom elements with role="checkbox" and is redundant on a native <input type="checkbox"> since the browser already manages and communicates the state via the accessibility API. So it doesn’t add any value here.

Looking Ahead to Part 2

So far, we’ve seen that AI can be a valuable aid in improving accessibility for basic, “good” HTML components. It identifies missing associations and suggests appropriate ARIA attributes for simple use cases. But what happens when complexity increases?

In the second part of this article series, we’ll explore the more challenging categories — “The Bad” and “The Ugly.” We’ll examine where AI reaches its limits and what strategies developers need to ensure accessibility even for complex and heavily styled components. Stay tuned!