DEV Community: Alexander Thalhammer

Why Angular ARIA in v21 is pretty neat

Alexander Thalhammer — Mon, 01 Dec 2025 21:48:45 +0000

Angular ARIA is a collection of headless, accessible directives that implement common WAI-ARIA patterns. The directives handle keyboard interactions, ARIA attributes, focus management, and screen reader support. All you have to do is provide the HTML structure, CSS styling, and business logic!

You feel like you've already read this before? Perfectly possible, because I've just copied and pasted the paragraph from the official Angular ARIA docs. Why should I reinvent the wheel, right? It perfectly summarizes the concept.

So the Angular team just (together with v21 on Nov 19th, 2025) released a brand-new collection of components – I mean directives – that implement common web patterns while letting you choose your own HTML, styling (CSS, SCSS, or even Tailwind), and business logic (I'd suggest TypeScript).

This is pretty much the opposite approach of Angular Material, which is an opinionated Plug & Play Design System. Both are built on top of the Angular CDK A11y package. So what do we get here?

Components

In the first release with v21, the following 12 components / directives / UI patterns are available:

search and select	navigation / menu	content organization
Autocomplete	Menu	Accordion
Listbox	Menubar	Tabs
Select & Multiselect	Toolbar	Tree
Combobox		Grid

There are – of course – plans to extend this in the future 😏

Why is this neat?

Using the Angular ARIA directives is a great way to build Angular apps by offloading some of the heavy lifting to the Angular team while still allowing full customization and user-interface branding. BTW: Check out Jessica's talk at ViteConf on YT for other things in NG v21 that are neat.

When to use Angular ARIA?

You know how to style things (at least Senior in CSS)
You build a custom Design System or an enterprise component library
You don't use any Design System and instead handcraft everything yourself

When to avoid Angular ARIA?

You don't know how to style (Junior in CSS – join my NG Styling Workshop 🎨)
You use a Design System or an enterprise component library (should be covered there)
You don't care about accessibility (come on – don't be a jerk!)

Angular Styling Best Choices Matrix

Level	Angular Material 🔌	3rd-party DS 🎨	Angular ARIA ♿	Custom UI 🛠️	Custom DS 🏢
Design	🎨 Very opinionated	⚡ Plug & Play	🤷 Depends on you	🤷 Depends on you	🤷 Depends on you
Accessibility	⚡ Plug & Play	🙂 Usually okay	⭐ Best Choice	🤷 Depends on you	🤷 Depends on you
Effort	⭐ Very low	🙂 Medium	😬 High	😅 Only if 1 app	💀 Boss will kill ya
CSS Skills	🟢 None	🟡 Junior	🔴 Senior	🔴 Senior	🟣 Master
Customization	🔒 Hard	🤷 Depends	✔ Included	♾️ No limits	⭐ Best Choice
NG Updates	🚫 Don’t customize	😬 Sometimes painful	🙂 Smooth	😎 Very smooth	😵 A lot of work
Use it for	🚀 Prototypes & demos	💸 Low-budget/legacy	🌱 Greenfield	🎨 Hobbies	🏢 Enterprise apps

Stay tuned for my next blog post comparing popular 3rd party Design Systems for Angular vs. Angular Material.

Workshops

If you want to deep-dive into Angular, we offer a variety of workshops – in English and German.

Best Practices Workshop 📈 (including Design Systems & ARIA)
NG Styling Workshop 🎨 (including Design Systems)
Accessibility Workshop ♿ (including WAI ARIA)
Performance Workshop 🚀 (because it's neat)

Conclusion

Angular ARIA delivers headless, accessible building blocks for fully customizable Angular components. It shifts complexity – keyboard handling, ARIA attributes, focus management – to the Angular team, making it ideal for custom Design Systems and tailored UIs without relying on heavy, opinionated frameworks.

This blog post was written by Alexander Thalhammer. Comment it LinkedIn, bsky, X or Reddit.

Enhancing A11y with Angular CDK

Alexander Thalhammer — Thu, 05 Jun 2025 10:00:00 +0000

The @angular/cdk/a11y package is part of the Angular Component Dev Kit (CDK) and provides a collection of services, directives, SASS mixins, and other utilities to improve the Accessibility (A11y) of your Angular apps.

These tools are invaluable when building reusable, presentation-focused components with screen-reader announcements, robust keyboard and focus support, high-contrast theming, and more. They’re especially useful if you’re creating an Angular Component Library or a Design System.

Below are some of my favorites, along with brief code examples.

LiveAnnouncer for Screen Readers

The first service we want to highlight is the LiveAnnouncer. It allows you to announce messages to screen readers, which is particularly useful for providing feedback after user interactions. It's so simple: I often replace my console.log calls with announcements.

Here's an example of that:

private readonly liveAnnouncer = inject(LiveAnnouncer);

if (this.flights().length > 0) {
  // console.log('Found ' + this.flights().length + ' flights');
  this.liveAnnouncer.announce('Found ' + this.flights().length + ' flights');
} else {
  // console.log('No flights found');
  this.liveAnnouncer.announce('No flights found');
}

Make sure to test your announcements with the use of a screen reader.

Focus Tools

The Angular CDK also includes several tools supporting your focus management.

Focus Trap

The FocusTrap Directive allows you to trap focus within a specific element, ensuring that keyboard navigation remains within that element until the user explicitly exits it.

This is particularly useful for modal dialogs or pop-ups:

<dialog class="awesome-dialog" cdkTrapFocus>
  <!–- Yay, focus won't leave this element! -->
</dialog>

If you want focus to jump in automatically, enable the cdkTrapFocusAutoCapture flag:

<dialog class="awesome-dialog" cdkTrapFocus [cdkTrapFocusAutoCapture]="true">
  <!–- Yay, focus won't leave this element! -->
</dialog>

With this flag set to true, the focus will automatically be captured when the dialog opens. However, it may not always be the best choice to have an element automatically capture focus, so we can avoid this with a trick:

<dialog class="awesome-dialog" cdkTrapFocus [cdkTrapFocusAutoCapture]="true">
  <h3 class="awesome-dialog__title" tabindex="-1" cdkFocusInitial>...</h3>
  <!–- Yay, focus won't leave this element! -->
</dialog>

By adding cdkFocusInitial the title will be secretly focused initially. Since it has tabindex -1, it won't be focusable by keyboard navigation afterward.

Focus Regions

The Regions are a powerful tool that allows you to define a specific area of your application where focus should be managed. This is particularly useful for complex components like dropdowns or menus, where you want to ensure that focus remains within the component while it is open.

cdkFocusRegionStart
cdkFocusRegionEnd and optionally
cdkFocusInitial

Here's an example of how to use the Regions:

<nav>
  <a routerLink routerLinkActive="awesome" ariaCurrentWhenActive="page" cdkFocusRegionStart>Focus region start</a></li>
  <a routerLink routerLinkActive="awesome" ariaCurrentWhenActive="page">Another focusable link</a></li>
  <a routerLink routerLinkActive="awesome" ariaCurrentWhenActive="page" cdkFocusInitial>Initially focused</a></li>
  <a routerLink routerLinkActive="awesome" ariaCurrentWhenActive="page" cdkFocusRegionEnd>Focus region end</a></li>
</nav>

Note: To learn about the ariaCurrentWhenActive please read my post on Accessible Angular Routes

Focus Monitor

The FocusMonitor is a service that allows you to monitor focus changes within your application. It can be used to track when an element gains or loses focus, which is particularly useful for debugging focus-related issues.

This service can be injected into your components or services, and you can subscribe to focus changes:

import { Component, DestroyRef, effect, ElementRef, inject, viewChild } from '@angular/core';
import { FocusMonitor, FocusOrigin } from '@angular/cdk/a11y';

@Component({
  selector: 'app-navbar',
  template: `<nav #observed class="awesome-nav-cnt"><!-- children --></nav>`,
})
export class AwesomeFocusMonitorComponent {
  private readonly destroyRef = inject(DestroyRef);
  private readonly focusMonitor = inject(FocusMonitor);
  private readonly observedElementRef = viewChild.required<ElementRef<HTMLElement>>('observed');

  constructor() {
    effect(() => {
      const observedElementRef = this.observedElementRef(); // effect will run when the view is initialized
      this.focusMonitor.monitor(observedElementRef, true).subscribe((origin: FocusOrigin) => console.log(origin));
      this.destroyRef.onDestroy(() => this.focusMonitor.stopMonitoring(observedElementRef));
    });
  }
}

This is particularly useful for debugging focus-related issues, as it allows you to see when an element gains or loses focus.

FocusOrigin can be one of the following:

'mouse' the element was focused with the mouse
'keyboard' it was focused with the keyboard
'touch' it was focused by touching on a touchscreen
'program' it was focused programmatically, whereas
null indicates the element was blurred

So, this is also useful to check if a touch device is being used 😏

Styling utilities

The Angular A11y package also includes two useful Sass mixins.

Hidden Elements

Screen readers and other assistive technology skip elements that have display: none, visibility: hidden, opacity: 0, height: 0, or width: 0. In some cases, you may need to visually hide an element while keeping it available to assistive technology (e.g. Screen Readers).

@use '@angular/cdk';

@include cdk.a11y-visually-hidden();

<div class="awesome-toggle">
  <input type="checkbox" class="cdk-visually-hidden" />
</div>

High Contrast Mode

Some operating systems and/or devices include a High Contrast Mode. The Angular A11y package provides a Sass mixin that lets you define styles that only apply in high contrast mode. To create a high contrast style, just wrap it into the high-contrast mixin.

@use '@angular/cdk';

button {
  @include cdk.high-contrast {
    outline: 3px solid gold;
  }
}

The mixin works by targeting the forced-colors media query.

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility-related topics)
🚀 Performance Workshop

Conclusion

With these tools, you can significantly enhance the accessibility of your Angular Apps. They help ensure that your components are not only functional but also user-friendly for everyone, including those with disabilities.

One last thing: In this Code lab by Google, you can find some exercises on the most important Angular CDK A11y tools https://codelabs.developers.google.com/angular-a11y#8

That's all folks!

This is the last edition of our A11y series. I hope you found it helpful and learned something new about making your Angular Apps more accessible and user-friendly for all of us, and that you are ready for the European Accessibility Act (EAA). If uncertain, please go back to the start of the A11y blog series.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

References

Angular CDK Accessibility – official docs
Google codelab on A11y by Emma Twersky

Building Accessible Forms with Angular

Alexander Thalhammer — Mon, 02 Jun 2025 10:00:00 +0000

Accessible Angular Forms are essential to ensure that all our users – including those with disabilities – can interact with our Angular App effectively. By implementing forms with Accessibility (A11y) in mind, we meet legal (EAA 2025 ♿) and ethical standards, and create a more inclusive experience. Accessible forms work better with screen readers, keyboard navigation, and assistive technologies – which not only helps users with impairments but also enhances the overall UX of our Angular Apps.

Angular Forms

In Angular, we have two types of forms:

Template-driven Forms: These are simpler and more declarative, relying on Angular Directives to create forms. They are built around the NgModel directive and generally used for simple forms. As the name suggests, these are implemented in the template through attributes.
Reactive Forms: These are more powerful and flexible, allowing for complex form structures and dynamic validation. They are built in the component class around the FormGroup and FormControl classes. Most often the FormBuilder service is used to create the forms.

In 2025, the Angular team is expected to work on Signal integration for Angular Forms.

However, no matter which type of form you choose – and whether you migrate from Observables to Signals or not – the goal is to ensure that your forms are accessible to all users. This includes providing proper labels, error messages, and keyboard navigation. To keep the focus on A11y, we will use the simpler template-driven approach without any reactivity in our examples.

Keyboard Navigation & Tab Focus

Keyboard navigation is a critical part of form A11y. Many users rely on the keyboard – rather than a mouse – to move through a form using the Tab, Shift + Tab, Arrow, and Enter keys. Ensuring a logical tab order, using semantic HTML elements like <label>, <input>, <button>, and avoiding custom controls that break default behavior, helps users navigate efficiently. You should not change the order. However, you can add tabindex="0" to include non-interactive elements or custom components, and use tabindex="-1" to remove elements from the tab order.

Additionally, visual focus indicators (like outlines, at least 2 if not 3px width) should be clearly visible to show which element is currently active. When done right, keyboard-friendly forms not only improve A11y but also lead to a smoother and more intuitive experience for all users 😎

Form Fields

Labels & type attribute

To ensure A11y, always associate <label> elements with their corresponding form controls using the for and id attributes. This improves support for screen readers and enables better keyboard navigation – clicking a label should focus the related input. Make sure each id is unique, especially when using multiple forms on the same page. Additionally, specify the correct type for all <input> and <button> elements to ensure proper behavior, like submitting a form when pressing Enter on a <button type="submit">.

<label for="from">From</label> <input type="text" name="from" id="from" [...] />

Grouping fields

When we have a group of related inputs, especially radio buttons or checkboxes, screen readers benefit from extra semantic context by <fieldset> and <legend>:

<fieldset>
  <legend>Flight Class</legend>
  <label for="economy">Economy</label>
  <input type="radio" name="class" id="economy" value="economy" />
  <label for="business">Business</label>
  <input type="radio" name="class" id="business" value="business" />
</fieldset>

This provides context for assistive tech. Without this, users may hear "Economy" and "Business" without understanding they are part of a group. The <fieldset> element groups related controls, while the <legend> provides a caption for the group.

Required fields

When a form element (like <input>, <select>, or <textarea>) must have a value, use the required attribute. This prevents form submission unless the required fields are filled out, and helps users with assistive technologies understand which fields need valid content. For example, add the required attribute to both input fields in your form, and consider adding an asterisk (*) as an additional visual indicator.

<label for="name">Name (*)</label> <input type="text" name="name" id="name" required />

Autocomplete

The autocomplete attribute is a powerful tool for improving the user experience in forms. It allows browsers to remember and suggest previously entered values, making it easier for users to fill out forms quickly. By using the autocomplete attribute, you can specify the type of data expected in each field, such as name, email, or address. This not only enhances usability but also helps with A11y by providing clear context for screen readers and assistive technologies.

<input type="text" name="phone" autocomplete="phone" />

To avoid autocomplete, we should set the autocomplete attribute to off. This is especially useful for sensitive information like passwords or when you want to ensure that users enter fresh data.

<input type="password" name="password" autocomplete="off" />

ARIA attributes

ARIA attributes (more on them in our last post) can enhance the A11y of our Angular Forms by providing additional context to assistive technologies when native HTML alone isn’t enough. Attributes like aria-label or aria-labelledby can offer accessible names for form controls when visible labels aren’t practical. While ARIA should never replace semantic HTML, it’s a powerful tool to bridge A11y gaps and ensure all users can understand and interact with your forms effectively.

<input type="search" name="search" aria-label="Search flights" placeholder="Search..." />

For validation, aria-invalid="true" can indicate a validation error and aria-describedby can provide additional context or instructions. For example, if a user enters an invalid email address, you can set aria-invalid="true" on the input field and use aria-describedby to point to an error message that explains the issue.

@let hasFromErrors = flightSearchForm.controls['from'] && flightSearchForm.controls['from'].touched && flightSearchForm.controls['from'].errors;

<input type="text" name="from" id="from" required [attr.aria-invalid]="!!hasFromErrors" [attr.aria-describedby]="hasFromErrors ? 'from_error' : null" />

Speaking about error messages, let's take a look at how to handle them.

Error messages

Accessible error messages help all users understand and correct form issues. Use aria-describedby (as in the example above) to link inputs to their error messages, and add aria-live="polite" to ensure screen readers announce them when they appear. Messages should be clear, concise, and not rely on color alone – always provide text or icons for better clarity.

Personal preferences of error messages:

only after user interaction with the form: on blur ("touched" in Angular) or after submitting.
focus on the first invalid control (see code example below) upon submitting.
inline with the form fields, not at the top or bottom of the form.
after the form field, not before.
in (dark) red and with an icon (e.g., ❌) to make them more visible.

export class FlightSearchComponent {
  private readonly document = inject(DOCUMENT); // for the focus
  private readonly flightSearchForm = viewChild.required<NgForm>('flightSearchForm');

  protected onSearch(): void {
    if (this.flightSearchForm()?.invalid) {
      this.markFormGroupTouched(this.flightSearchForm());
      this.focusFirstInvalidControl(this.flightSearchForm());
      return;
    }

    // do the search
  }

  private markFormGroupTouched(formGroup: FormGroup): void {
    for (const key of Object.keys(formGroup.controls)) {
      const control = formGroup.get(key);
      if (control instanceof FormGroup) {
        this.markFormGroupTouched(control);
      } else {
        control?.markAsTouched();
      }
    });
  }

  private focusFirstInvalidControl(formGroup: FormGroup): void {
    for (const key of Object.keys(formGroup.controls)) {
      const control = formGroup.get(key);
      if (control?.invalid) {
        const invalidControl = this.document.querySelector(`[name="${key}"]`);
        (invalidControl as HTMLElement)?.focus();
        break;
      }
    }
  }
}

<form #flightSearchForm="ngForm">
  <label for="fromAirport">From (*)</label>

  @let hasFromErrors = flightSearchForm.controls['from'] && flightSearchForm.controls['from'].touched && flightSearchForm.controls['from'].errors;

  <input
    type="text"
    name="from"
    id="fromAirport"
    required
    [minlength]="minLength"
    [maxlength]="maxLength"
    [pattern]="pattern"
    [attr.aria-invalid]="!!hasFromErrors"
    [attr.aria-describedby]="hasFromErrors ? 'fromErrors' : null"
    [(ngModel)]="from"
  />

  @if (hasFromErrors) {
  <app-flight-validation-errors id="fromErrors" [errors]="flightSearchForm.controls['from'].errors" fieldLabel="From" />
  }
</form>

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility-related topics)
🚀 Performance Workshop

Conclusion

Building accessible forms in Angular is not just a best practice – it’s a commitment to creating better experiences for everyone. With just a few thoughtful choices, you can make your forms inclusive, intuitive, and ready for the future. For more information on Angular and Accessibility, check out my A11y blog series.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

ARIA roles and attributes in Angular

Alexander Thalhammer — Fri, 30 May 2025 13:34:52 +0000

ARIA (short for Accessible Rich Internet Applications) roles and attributes are used to improve Accessibility of our Angular apps – especially for users who rely on assistive technologies like screen readers, voice control, or alternative input devices. Using ARIA is essential for building inclusive, user-friendly web apps.

About ARIA

ARIA was developed by the World Wide Web Consortium’s Web Accessibility Initiative (WAI) to enhance the accessibility of dynamic web content. The WAI also is the organization behind the Web Content Accessibility Guidelines (WCAG), which provide a comprehensive framework for A11y – more about WCAG in the intro of this A11y blog series.

Originating in the early 2000s, ARIA was created to bridge the gaps in native HTML, ensuring that modern, interactive and single-page applications are usable by people with disabilities ♿

ARIA in Angular

In Angular, ARIA roles and attributes can be easily integrated into your components. You can use them directly in your HTML view templates, just like any other HTML attribute. Angular also provides built-in support for ARIA through directives and bindings, making it easier to manage ARIA properties dynamically.

When using static values, you can simply add them to your HTML elements or components:

<!-- Static ARIA attributes require no extra -->
<button type="button" aria-label="Close">X</button>

However, when you want to bind ARIA attributes dynamically, you should use Angular's property binding syntax ("[]" square brackets) including the "attr." prefix:

<!-- Dynamic ARIA attribute property binding with "attr." prefix -->
<button type="button" [attr.aria-label]="myActionLabel">…</button>

ARIA vs. Semantic HTML

While ARIA is a powerful tool for enhancing accessibility, it should be used as a last resort. Native semantic HTML elements and attributes are preferred whenever possible, as they provide built-in accessibility features that ARIA does not have to replicate. Always prefer native elements like <button>, <label>, <nav> and <header> over their ARIA counterparts. For example, instead of using role="button" on a <div>, use a <button> element.

ARIA Roles

Speaking about ARIA roles, they define what an HTML element is or how it should behave – when native HTML elements are not applicable. They tell assistive technologies how to interpret an element and its purpose within the page. Roles are particularly useful for custom components that don’t have native semantic meaning.

Most commonly used ARIA roles

Here is a not exhaustive list of some ot the most commonly used ARIA roles:

role="button" (prefer <button>) indicates an interactive element that triggers an action.
role="main" (prefer <main>) the main content of your app – typically <router-outlet />.
role="complementary" (prefer <aside>) denotes content that complements – like a sidebar.
role="navigation" (prefer <nav>) denotes a section of navigation links – like your route nav.
role="alert" used for important messages that should be immediately announced.
role="dialog" signifies a modal or popup window.
role="listbox" used for a widget that allows the user to select from a list of options.
role="tablist" composes a tabbed interface.
role="tab" represents a selectable tab in a tabbed interface.
role="tabpanel" the container for the content associated with a tab.

Find a comprehensive list of all ARIA roles by MDN.

Examples

This could be a <app-dialog> component:

<app-dialog role="dialog" aria-labelledby="dialogTitle" aria-modal="true" cdkFocusTrap>
  <h2 id="dialogTitle">{{ dialogTitle() }}</h2>
  <p>{{ dialogContent() }}</p>
  <button type="button" (click)="onClose()">Close</button>
</app-dialog>

In this simple example, the role="dialog" indicates that this is a dialog window. The aria-labelledby attribute associates the dialog with its title, and aria-modal="true" indicates that the dialog is modal, meaning it prevents interaction with the rest of the page until closed. Note that we also use the cdkFocusTrap directive to ensure that (keyboard navigation) focus is trapped within the dialog while it is open.

Another example could be a tab interface:

<app-tablist role="tablist">
  @for (tab of tabs(); track tab.id) {
    <button role="tab" aria-controls="panel_{{ tab.id }}" id="tab_{{ tab.id }}"
            [attr.aria-selected]="activeTab() === tab.id ? 'true' : 'false'">
      {{ tab.label }}
    </button>
  } @empty {
    No tabs available.
  }
</app-tablist>
@for (tab of tabs(); track tab.id) {
  <app-tab role="tabpanel" aria-labelledby="tab_{{ tab.id }}" id="panel_{{ tab.id }}">
    {{ tab.content }}
  </app-tab>
}

In this example, we have a tabbed interface. The role="tablist" indicates that this is a list of tabs. Each tab has the role="tab" and is associated with its corresponding panel using aria-controls. The aria-selected attribute indicates which tab is currently selected. The panels have the role="tabpanel" and are associated with their respective tabs using aria-labelledby.

ARIA Attributes

ARIA attributes provide additional details about an HTML element’s state, properties or relationships. They enhance the semantic meaning of your Angular components and other HTML elements, especially when default HTML does not fully describe an element’s behavior.

We distinguish between states and properties. States are dynamic and can change over time, while properties are static and describe the element's characteristics.

Most commonly used ARIA attributes

Widget attributes (states and properties)

aria-disabled (state/property): indicates whether an element is disabled or not – not necessary if native disabled is used.
aria-required (property): indicates that user input is required before submitting a form – not necessary if native required is used.
aria-expanded (state): communicates whether an element, such as a collapsible menu, is expanded or collapsed.
aria-hidden (state): indicates whether an element should be exposed to assistive technologies.
aria-invalid (state): indicates whether the value of an input field is valid or invalid.

Live region attributes (states)

aria-live: specifies how updates to content should be announced to the user (e.g., assertive for error messages).
aria-busy: indicates whether an element is currently being updated (e.g., loading spinner).

Drag-and-Drop attributes (states)

aria-grabbed: indicates whether an element is currently being dragged (e.g., true when dragging).

Relationship attributes (properties)

aria-label: provides a text alternative for elements that may not have visible text.
aria-labelledby: identifies an element (or elements) that labels the current element.
aria-describedby: identifies an element (or elements) that describes the current element.
aria-controls (state): references the element(s) whose content is controlled by the current element.

And here is again the full list of all ARIA attributes by MDN.

Examples

A toggle button using aria-label and aria-expanded:

<button
  type="button"
  aria-label="Toggle navigation menu"
  [attr.aria-expanded]="isMenuOpen() ? 'true' : 'false'"
  (click)="onToggleNav()">
  <i class="icon-menu"></i>
</button>

In this simple example, the aria-label attribute provides a text alternative for the button, indicating its purpose. The aria-expanded attribute indicates whether the navigation menu is currently open or closed. This is important for screen reader users, as it helps them understand the state of the button.

Using aria-live combined with role="alert" for an error message:

@let showFromErrors =
  flightSearchForm.controls.from.errors &&
  flightSearchForm.controls.from.touched;

<input
  [...]
  id="fromAirport"
  [attr.aria-invalid]="!!showFromErrors"
  [attr.aria-describedby]="showFromErrors ? 'fromAirportErrors' : null"
/>
@if (showFromErrors) {
  <app-flight-validation-errors
    aria-live="assertive"
    role="alert"
    id="fromAirportErrors"
    fieldLabel="From"
    [errors]="flightSearchForm.controls.from.errors"
  />
}

In this example, the aria-live attribute is set to assertive, which means that the screen reader will announce the error message immediately when it appears. The role="alert" indicates that this is an important message. Additionally, the aria-invalid attribute is used to indicate that the input field has validation errors and the aria-describedby attribute is used to associate the error message with the input field. Note that the aria-describedby attribute is set to null when there are no errors. This ensures that it's not present in the rendered DOM when not needed.

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility-related topics)
🚀 Performance Workshop

Conclusion

Implementing ARIA in Angular is essential for building web apps that are both accessible and inclusive. By leveraging ARIA roles and attributes appropriately, developers can bridge gaps where native HTML falls short, ensuring that all users have a positive experience. This approach not only meets accessibility standards but also lays the foundation for user-centric and future-proof design.

In the next edition of our A11y blog series, we'll cover Accessible Angular Forms.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

References

Accessibility in Angular Applications by Zama Khan Mohammed
Accessibility in Angular 17 by Amir Saeed
ariaCurrentWhenActive – official docs
ARIA roles
ARIA attributes

Accessible Angular Routes

Alexander Thalhammer — Tue, 27 May 2025 15:29:04 +0000

This article explains how to use Angular Router features to achieve quick wins in improving Accessibility (A11y). It is the third edition of our A11y blog series. If you want to enhance your Angular A11y skills, please make sure to read the other articles in this series as well.

Page Titles

Does your Angular App look like this if you open it in multiple tabs?

If it does, you should definitely consider adding unique page titles for each route. The very easy-to-use Route.title feature shipped with Angular v14 in 2022, yet many Angular Developers are still not using it 😱. Please take a look and adopt it in your Angular Apps.

Route.title

Use this built-in Router feature to automatically update the page <title> after each successful navigation, enhancing both accessibility and UX for all of us. To enable it in your primary <router-outlet />, you only need to set the title property in your routes configuration array:

export const routes: Routes = [
  {
    path: 'demo',
    title: 'Look how easy it is to use',
    component: DemoComponent,
  },
];

This will update the page title in the browser tab and make it accessible to screen readers.

In larger Angular Apps, setting page titles can become inconsistent due to the lack of a common prefix or suffix for routes.

Global Page Title Strategy

To address this, you can extend Angular's abstract TitleStrategy class and implement your custom page title strategy:

// [imports]

@Injectable()
export class PageTitleStrategy extends TitleStrategy {
  private readonly title = inject(Title);

  updateTitle(routerState: RouterStateSnapshot): void {
    const pageTitle = this.buildTitle(routerState);
    if (pageTitle) {
      this.title.setTitle(pageTitle + ' – Demo');
    } else {
      this.title.setTitle('Link to Demo below!');
    }
  }
}

Then add the custom title strategy to your app.config.ts:

// [imports]
import { PageTitleStrategy } from "./page-tite-strategy";

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(withIncrementalHydration()),
    provideExperimentalZonelessChangeDetection(),
    provideRouter(routes),
    { provide: TitleStrategy, useClass: PageTitleStrategy }, // add this line
  ],
};

Dynamic Page Titles using Angular Router Params

To create dynamic page titles using Angular Router parameters, follow these steps:

First, we set up the withComponentInputBinding() function to bind the route parameters to your component inputs:

// [imports]

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(withIncrementalHydration()),
    provideExperimentalZonelessChangeDetection(),
    provideRouter(routes, withComponentInputBinding()), // add feature to router
    { provide: TitleStrategy, useClass: PageTitleStrategy },
  ],
};

Then, we add the parameter to the route definition:

export const routes: Routes = [
  // [...]
  {
    path: 'demo/:id',
    title: 'Demo #id', // note that this will be ignored and replaced by the dynamic title
    loadComponent: () => import('./demo/demo.component'),
  },
];

Now, we can simply add a input signal to the component that will automatically receive the route param (thanks to the withComponentInputBinding() feature):

// [imports & decorator]
export class DemoComponent {
  readonly id = input<number | undefined>();

  // [...]
}

export default DemoComponent;

Finally, we can use an effect on our id input signal to display the dynamic page title:

// [imports & decorator]
export class DemoComponent {
  readonly id = input<number | undefined>();
  private readonly title = inject(Title);

  constructor() {
    effect(() => this.title.setTitle(this.id() !== undefined ? `Page #${this.id()} - Demo` : 'Page - Demo'));
  }
}

export default DemoComponent;

Now, when you navigate to /demo/1, the page title will be set to Page #1 - Demo.

All Together Now

To bring it all together – with the global page title strategy – we add another method to the PageTitleStrategy class and provide it in root:

// page-title-strategy.ts
import { RouterStateSnapshot, TitleStrategy } from '@angular/router';
import { inject, Injectable } from '@angular/core';
import { Title } from '@angular/platform-browser';

@Injectable({
  providedIn: 'root',
})
export class PageTitleStrategy extends TitleStrategy {
  private readonly title = inject(Title);

  updateTitle(routerState: RouterStateSnapshot): void {
    this.setTitle(this.buildTitle(routerState));
  }

  setTitle(pageTitle?: string): void {
    if (pageTitle) {
      this.title.setTitle(`${pageTitle} – Demo`);
    } else {
      this.title.setTitle('Page title like a pro');
    }
  }
}

And here is the final version of the dynamic page title effect in the DemoComponent using our injected PageTitleStrategy:

// demo.component.ts
// [imports & decorator]
export class DemoComponent {
  private readonly pageTitleStrategy = inject(PageTitleStrategy);

  readonly id = input<number | undefined>();

  constructor() {
    effect(() => this.pageTitleStrategy.setTitle(this.id() !== undefined ? `Page #${this.id()}` : 'Page'));
  }
}

export default DemoComponent;

Now you can set the page title depending on the route params and have a consistent suffix for all routes in your Angular App.

Pretty nice, huh? Check out the full source code in the title-strategy branch of my GitHub repo.

RouterLinkActive

The RouterLinkActive directive is another powerful and lightweight tool for indicating the active state of navigation links in your Angular App. It allows you to apply CSS styles to navigation links based on their active state, making it easier to create appealing and accessible menus.

<!-- nav.component.html -->
<nav>
  <a [routerLink]="demo" routerLinkActive="active">Demo</a>
  <!-- ... -->
</nav>

<!-- nav.component.scss -->
nav a.active {
  color: var(--nav-link--active__color);
  text-decoration: none;
}

Fine-tuned control with `routerLinkActiveOptions`

Since Angular v14, you can use the routerLinkActiveOptions directive to fine-tune the active state of your links. Where options will have either the shape of IsActiveMatchOptions:

export declare interface IsActiveMatchOptions {
  fragment: 'exact' | 'ignored';
  matrixParams: 'exact' | 'subset' | 'ignored';
  paths: 'exact' | 'subset';
  queryParams: 'exact' | 'subset' | 'ignored';
}

Or, just a boolean named exact:

{
  exact: boolean
}

To apply exact matching, add the routerLinkActiveOptions directive to your link:

<!-- nav.component.html -->
<nav>
  <a
    routerLink="/demo"
  routerLinkActive="active"
  [routerLinkActiveOptions]="{ exact: true }"
  >
  Demo
  </a>
  <!-- ... -->
</nav>

Indicate current page `ariaCurrentWhenActive`

A final quick win in A11y in Angular is to highlight the current page link in the nav for screen readers via aria-current: We need to add the aria-current="page" attribute. This can easily be done using the ariaCurrentWhenActive input on the routerLinkActive directive by setting its value to "page":

<!-- nav.component.html -->
<nav>
  <a
    routerLink="/demo"
    routerLinkActive="active"
    [routerLinkActiveOptions]="{ exact: true }"
    ariaCurrentWhenActive="page"
  >
    Demo
  </a>
  <!-- ... -->
</nav>

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility related topics)
🚀 Performance Workshop

Conclusion

Implementing Angular's built-in router features is a simple yet powerful way to boost your A11y 🚀

By leveraging dynamic page titles, a global title strategy, and fine-tuning active link indicators with RouterLinkActive and ariaCurrentWhenActive, you can create a more inclusive UX that benefits everyone – from seasoned Devs (like me 😂) to users who rely on assistive technologies. These strategies not only improve UX but also help standardize navigation and page management across all Angular Apps. Back to our example from the beginning, now our browser tab bar looks like this:

I think this is a great example of a quick win! Keep playing with these features and explore the rest of our A11y blog series for more insights on building accessible, high-performing web apps.

In the next edition of our A11y blog series, we'll cover more ARIA roles and attributes.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

References

GitHub repo of demo, by Alexander Thalhammer
Angular v14 – official blog post by Emma Twersky
Tweet about Route title by Emma Twersky
Page Titles With The Router by Brandon Roberts
Router Link Accessibility Features by Brian Treese
Make it accessible: Navigation in Angular by Daniel Marin
ariaCurrentWhenActive – official docs

Accessibility Testing Tools for Angular

Alexander Thalhammer — Mon, 21 Apr 2025 15:50:52 +0000

Let me introduce you to my curated selection of Accessibility Testing Tools for Angular Apps. This article is the second edition of our A11y blog series. If you want to learn more about Accessibility in Angular, please check out the other articles in this series.

Introduction

Automated testing can never replace manual testing (at least so far, in 2025). There are tools that can identify some or many A11y issues, but no tool can certify that a web app is fully accessible. Manual testing ensures that you test for a breadth of A11y concepts that include logical content order and feature parity.

However, automated testing is fast and - at least to me - some kind of entertaining work 🚀

Chromium Browser

First, please stop using the lame Firefox (slow open-source browser sponsored mainly by Google). I strongly recommend using a Chromium based browser! Safari is okay for people who love their golden Apple cage. Here are some browsers that I can recommend:

Vivaldi (Privacy & Linux)
Brave (Privacy & Ad blocker)
Arc (for something completely different) and even
Edge (for Windows machines without Admin privileges)

Personally, I prefer using a clean Google Chrome on my Macs and my Pixel. Just like I prefer a clean Google Android and have been happily sticking to Nexus (4, 5, 5) and later Pixel (3a, 6a, 9 Pro soon 😎 - review in German) for over a decade now. However, if you don't want to share your data with Google - those Chromium browsers listed above (except Edge) are the better choice for sure.

While the Spaces feature of Arc is pretty interesting, I just use different Chrome users for my different jobs. E.g., one of them for everything related to Angular Architects - like reading this post 🤓

Did you notice that Chromium DevTools have a built-in Accessibility Tree view?

Chromium Extensions

Before we talk about a selection of my favorite Accessibility Tools, please add the following extensions to your browser (at least temporarily):

Angular Dev Tools (should be there already since you're here 😏)
WAVE A11y Testing Tool, 500k users
axe DevTools A11y Testing Tool, 300k users
Accessibility Insights A11y Testing Tool, 100k users
Read Aloud Screen Reader (OS-based Screen Readers listed at the end of the post are better, though)
HeadingsMap (partially related to A11y, for heading structure)

You may need to restart your browser for the just-added extensions to work.

Please note that three of them are used exclusively for A11y testing. Once you've found your favorite A11y weapon of choice, you might want to remove the other two. My personal preference will be mentioned below!

Automated Testing

Identify issues and how to know what to fix

The A11y Testing Tools allow you to quickly and easily check things like the presence of alt text on an image or the contrast ratio of a text color. You can think of these tools as linters; they can recognize that alt text is present, but you must manually check that the content is logical and provides value.

Some tools might find a lot of errors or warnings on your app or web property. Please don't feel overwhelmed in such a case and start improving your A11y step-by-step. Here is a customizable quick reference to Web Content Accessibility Guidelines (WCAG) 2.2 requirements (success criteria) and techniques:

https://www.w3.org/WAI/WCAG22/quickref/

You'll need to find a prioritization for your issues. The WCAG's levels (A, AA and AAA) will help you get started.

Now, finally, the selection of my favorite Accessibility Testing Tools 🥳

Angular ESLint (only for Angular apps)

You can use the Angular ESLint package to lint your code for automatable A11y attributes. In eslint.json, make sure to add the a11y ruleset plugin @angular-eslint/template/accessibility to your HTML templates:

{
  "overrides": [
    /* [...] */
    {
      "files": ["*.html"],
      "extends": [
        "plugin:@angular-eslint/template/recommended",
        /* add the following line */
        "plugin:@angular-eslint/template/accessibility"
      ],
      "rules": {
         /* [...] */
      }
    }
  ]
}

To add Angular ESLint to your own Angular app, simply run:

ng add @angular-eslint/schematics

Note: With the newest version, the plugin @angular-eslint/template/accessibility is included by default.

For more information, see the latest Angular ESLint rules on GitHub.

WAVE Chrome Extension

If you haven't done so already, install the WAVE Chrome extension.
Click on the Wave icon to run the WAVE Ally test on the current page.

WAVE Web Service

If you want to check a public web property, you can also try the WAVE Web Accessibility Evaluation Tool.

Axe Chrome Dev Tools

If you haven't done so already, install the axe DevTools extension.
Open your DevTools and select the axe DevTools tab.
Click Scan all of my page to run an axe Ally scan on the current page.

Lighthouse Dev Tools

Open your DevTools and select the Lighthouse tab.
The options Navigation and Mobile (or Desktop) are okay.
Select the Accessibility checkbox and deselect all other checkboxes.
Click Generate report to run a Lighthouse A11y audit.
Check the results of your audit.

PageSpeed Insights Web Service

Note: For public properties, you can also use Google's PageSpeed Insights to run the lighthouse A11y test.

Accessibility Insights Dev Tools

If you haven't done so already, install the Accessibility Insights extension.
Open it by clicking on the extension icon and selecting Accessibility Insights.
Click FastPass to run a quick first test of your page.

Run A11y Tests

If you haven't done so already, run some automated tests on your machine now 💻

Manual (Auditory) Testing

Besides manual testing, you want to do auditory accessibility tests. You want to turn on your machine's built-in screen reader and navigate through your (Angular) app with keyboard navigation.

Screen Reader

You can use any one of these screen readers:

NVDA (Windows, free & recommended for A11y testers)
Jaws (Windows, expansive & favorite choice of people with handicapped sight)
Narrator (Windows, built-in)
Voice Over (Mac/iOS, built-in but great)
Talkback (Android, built-in but great)
Orca (Linux, free)
Read Aloud Chrome Extension (not so great, IMHO)

Accessibility Workshop

If you want to learn Angular, we offer a variety of workshops – both in English and German.

Accessibility Workshop ♿
Best Practices Workshop 📈 (including accessibility related topics)
Performance Workshop 🚀

Conclusion

Tools are always a matter of personal preference and taste. So, I'd like to invite you to try out some of the recommended tools and choose your own favorite one. Nevertheless, my favorite of all is the WAVE extension and web service. Happy testing!

In the next edition of our A11y blog series, we'll show you how to use the Angular Router for better accessibility.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

Web Accessibility (A11y) in Angular – Introduction

Alexander Thalhammer — Mon, 07 Apr 2025 19:42:24 +0000

This article will get you started into Accessibility in Angular, right on time for the European Accessibility Act (EAA) which will become effective on June 28th 2025, but more on that later. We'll cover the history of Web Accessibility, the Web Content Accessibility Guidelines (WCAG), and of course the EAA itself. So make sure to follow it to be prepared for the EAA and to learn how to make your Angular Apps more accessible.

The article is intended for developers, product owners, and anyone interested in making their Angular Apps more accessible. It's also the first edition kicking of our A11y blog series, which will cover topics such as:

Web Accessibility Introduction (this post): An overview of the history, statistics and regulatory framework of Web Accessibility.
Accessibility Testing Tools: My top picks for testing your Angular app for accessibility issues.
Accessible Angular Routes: Quick wins to enhance your app's accessibility using the Angular Router.
ARIA roles and attributes: Best practices for implementing WAI-ARIA roles and attributes in Angular.
Accessible Angular Forms: Guidelines for building Angular forms that everyone can use.
Enhancing A11y with CDK: Exploring some elements of the Angular CDK a11y package.

Brief History of Web Accessibility

Tim Berners-Lee, the inventor of the World Wide Web, envisioned it as a platform for universal access regardless of physical or cognitive abilities.
The term accessibility (short A11y, like I18n) refers to the design of products, devices, services, or environments for people with disabilities.

Disability Statistics

While estimates suggest that one in four individuals in the EU has some form of disability, finding exact data is challenging. Therefore, we focus on Germany using the numbers of the Statistische Bundesamt (Federal Statistical Office of Germany) from 2023:

7.86m people (9.4% of the pop.) in Germany have a severe disability
1.85m people (2.2% of the pop.) have problems with cerebral disorders, mental and psychological disabilities
1.63m people (2.0% of the pop.) have problems with mobility impairments
329k people (0.4% of the pop.) are considered blind or have severe vision impairment
324k people (0.4% of the pop.) are considered deaf or have severe hearing impairment

Although this data is specific to Germany, they offer insight into the broader prevalence of disabilities across Europe.
However, I think it's important to note that good A11y practices benefit not only people with disabilities but everybody.
For example, captions on videos help non-native speakers and those in noisy environments.
Here is an image by Microsoft showing the benefits of A11y for all kinds of circumstances:

W3C and the Web Accessibility Initiative (WAI)

In 1997, the World Wide Web Consortium (W3C) launched the Web Accessibility Initiative (WAI) to systematically address accessibility issues.
The WAI develops guidelines, called Web Content Accessibility Guidelines (WCAG) – version 1.0 released in 1999 – and continues to provide resources to make the web more accessible.

Web Content Accessibility Guidelines (WCAG)

The WCAG guidelines offer an internationally recognized framework for creating accessible web content and applications. The latest version, WCAG 2.2, was published in December 2023. Both WCAG 2.1 and 2.2 are widely adopted in regulatory standards across Europe and North America.

For a deep dive, check out the WCAG 2.2 Quick Reference. Here are some key points:

The Four Principles

The WCAG 2.2 guidelines are built and structured on four core principles that form the foundation for creating accessible digital content:

👀 Perceivable: Information must be presented in ways that users can perceive.
🕹️ Operable: Interface components must be operable across various devices and inputs.
🧠 Understandable: Content and navigation should be clear and easy to comprehend.
🛡️ Robust: Content must work reliably with current and future technologies, including assistive devices.

Illustration source.

Levels of Conformance

WCAG defines three levels of conformance:

🥉 Level A: The minimum level. It addresses the essential A11y features required for basic interaction. While meeting Level A ensures that essential content is accessible, some barriers may still exist.
🥈 Level AA: Building upon Level A, this level targets the most significant and common barriers. It enhances the UX by improving readability, navigation, and overall usability, and is widely regarded as the standard for many legal and organizational requirements (EAA!).
🥇 Level AAA: Representing the highest standard of A11y, includes the most rigorous criteria. Although achieving AAA ensures maximum accessibility, it may not be feasible for all types of content and is typically applied to specialized cases where the highest level of A11y is required.

So our recommendation (well and the lawmakers also have that opinion) is to aim for Level AA compliance, as it strikes a balance between A11y and practicality (aka affordability).

European Accessibility Act (EAA)

The European Accessibility Act (EAA) is a new (actually it's from 2019) EU directive that has to be fully implemented by June 28th 2025.
Based upon the mentioned WCAG 2.2, the EAA sets clear rules to ensure that web applications, websites, and other online services are accessible to everyone, including people with disabilities.
In essence, digital tools must be designed to remove barriers, allowing all users to access information and services without difficulty.

By focusing on web applications, the EAA pushes businesses and developers to create user-friendly, accessible online experiences.
The law helps people with disabilities have the same opportunities and also encourages innovation in web design and development.
In short, the EAA is a key step toward making the internet a more inclusive and in the end, more enjoyable space for all.

The EAA source (hint: don't follow this link): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32019L0882

National Implementation of the EU Directive

While we won’t cover every detail here, here are some examples of national implementations of the EAA. Interestingly, even though Switzerland is not an EU member, they were the first country implementing the EAA into national law 😀

🇨🇭 Switzerland: Accessibility Standard 3.0 (eCH-0059) – June 2020
- Official Website: ech.ch/en/standards/ech-0059/ (German / French)
🇩🇪 Germany Barrierefreiheitsstärkungsgesetz (BFSG) – July 2022
- Private website about the BFSG: bfsg-gesetz.de (German)
🇦🇹 Austria: Barrierefreiheitsgesetz (BaFG) – July 2023
- Austrian camber of commerce: About the BaFG (German)

Affected online services include

The EAA impacts a variety of digital services, including

📚 E-books: Digital (e.g. academic) books that enable the circulation and consultation of a mostly textual and graphical intellectual work.
🛒 E-commerce: Retail websites and mobile applications that facilitate online transactions are required to meet accessibility standards.
🏦 Online banking: Online and mobile banking platforms must be accessible, ensuring that financial services are usable for everyone.
🚌 Public & transportation services: In some cases, the Act also touches on digital services in areas like transport (e.g., online ticketing and check-in services) and audiovisual media services. However, note that public sector websites and mobile apps are governed by a different EU directive (the Web Accessibility Directive).

Although the EAA covers many services, there are areas where its application may still be ambiguous or unclear. For example, the EAA does not explicitly mention Angular or JavaScript frameworks, but it does require that certain web applications and websites are accessible to everyone.

Make sure to follow our A11y blog series to be prepared for the EAA and to learn how to make your Angular Apps more accessible.

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility related topics)
🚀 Performance Workshop

Conclusion

In this post, we explored the fundamentals of web accessibility — from its history and key statistics to the regulatory landscape, including the upcoming European Accessibility Act.
Whether you’re a developer, designer, or business owner, understanding and implementing accessibility best practices is essential for creating inclusive Angular Apps for everyone.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

Complete Guide for Server-Side Rendering (SSR) in Angular

Alexander Thalhammer — Thu, 04 Jul 2024 16:27:24 +0000

Updated on Mar. 23rd, 2025 for Hybrid Rendering & brandnew Incremental Hydration (now including demo) in Angular v19.2.

This comprehensive post includes a quick introduction to SSR, a detailed setup guide and several best practices with Angular v19 (released on Nov 19th, 2024), enhancing the initial load performance and thus the user experience of modern web applications built with Angular.

If you haven't upgraded to v19 yet, then what are you waiting for? In my humble opinion, the new Hybrid Rendering and Incremental Hydration features of v19 can already be used in production, even though they are still in Developer Preview:

See all Angular features in this Angular feature roadmap by Gerome Grignon. By the way, if you want to use Material and/or CDK with SSR, you need at least v18.

The Angular team has recently (well actually for quite some time) been putting in a huge effort and doing a fantastic job to help us improve the initial load time. SSR plays a significant role in achieving that goal for our framework of choice. Read my post from July 2023 to learn why initial load performance is so crucial for your Angular apps.

Essentials

Let's start with the basics. You can, of course, skip this section if you're already familiar with SSR, and continue with the next section about building.

Server-Side Rendering (SSR)

Server-Side Rendering (SSR) is a web development technique where the (in our case node) server generates the HTML content of a web page (in our case with JavaScript), providing faster initial load time. This results in a smoother user experience, especially for those on slower networks (e.g. onboard a train in 🇩🇪 or 🇦🇹 – which I happen to be a lot recently 😏) or low-budget devices. Additionally, it improves SEO and crawlability for Social Media and other bots like the infamous ChatGPT.

New Angular CLI projects will automatically prompt SSR (since Angular v17):

ng new your-fancy-app-name

For existing projects simply run the ng add command (since Angular v17):

ng add @angular/ssr

Warning: You might have to fix stuff manually (like adding imports of CommonJsDependencies) after adding SSR to your project 😬

Follow the angular.dev guide for detailed configuration. However, I'd recommend switching to the new Application Builder, which has SSR and SSG baked in (more on that in the build section below). Let's first clarify what SSG stands for.

Static Site Generation (SSG)

Static Site Generation (SSG) or Prerendering (like the Angular framework likes to call it), is the technique where HTML pages are prerendered at build time and then served as static HTML when a URL is visited. Instead of rendering live on demand, SSG generates the HTML once and serves the same pre-built HTML to all users. This provides even faster load times and further improves the user experience. However, since the HTML is being stored on the server, this approach is limited whenever dynamic content is needed.

Important note: For the use of SSG you don't need a node.js / express server. You can still ship your application from nginx or even Apache.

Full-application Hydration (preview in v16, stable since v17)

Hydration is the process where the prerendered static HTML, generated by SSR or SSG, is enhanced with interactivity on the client side. After the initial HTML is delivered and rendered in the browser, Angular's JavaScript takes over to "hydrate" the static content, attaching event listeners and thus making the page fully interactive. This approach combines the fast initial load times of SSR/SSG with the dynamic capabilities of a SPA, again leading to a better overall user experience.

Before Angular's Hydration feature, the prerendered static DOM would have been destroyed and replaced with the client-side-rendered interactive version, potentially resulting in a layout shift or a full browser window flash aka content flicker – both leading to bad results in performance tools like Lighthouse and WebPageTest. In my opinion, Angular SSR was not production-ready until supporting Non-Destructive Hydration. This has changed in 2023 since this feature has already become stable in Angular v17.

Please note: Since the introduction of Incremental Hydration in v19 (more on that later), the classic Hydration is referred to as Full-application Hydration. By the way, it's super easy to enable Hydration in Angular 💧

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(), // use v16 full-app hydration
  ],
};

If you're still using NgModules (for reasons), it becomes:

@NgModule({
  providers: [provideClientHydration()],
})
export class AppModule {}

Deferrable Views (preview in v17, stable since v18) with @defer

Deferrable Views, also called @defer blocks, are Angular's native primitive for declaratively defer loading components of your application. It can be used as an alternative to the router-based lazy loading through loadComponent() (used with Standalone Components) or loadChildren() (used with another routes definition array and formerly used with NgModules).

The @defer block allows you to specify when a component should be loaded and rendered, which can be based on various triggers like on idle, on viewport, on hover, on interaction etc. This is a great way to improve the initial load performance of your application by deferring the loading of non-critical components – for example everything below-the-fold – until they are needed. It can also be used to lazyload heavy libraries (like charts or complex tables). Learn more about the @defer block in my blog post.

Important: While Deferrable Views work completely independently of SSR, they can be used in combination with SSR to enforce client-side rendering (CSR) for certain components. This is especially useful for user-dependent content, such as user-specific lists or prices. The @defer block will render the placeholder on the server and then load the real content in the browser once it has been triggered.

Deferrable Views Demo

You can find a demo in the deferrable views branch in this repository on GitHub 😏

Event Replay (in preview since v18, but battle-proven by Google)

This example was taken from the official Angular blog. Consider an app that contains a click button like this:

<button type="button" (click)="onClick()">Click</button>

Previously, the event handler (click)="onClick()" would only be called once your application has finished Hydration in the client. With Event Replay enabled, JSAction is listening at the root element of the app. The library will capture events that (natively) bubble up to the root and replay them once Hydration is complete.

If implemented, Angular apps will stop ignoring events before Hydration is complete and allow users to interact with the page while it's still loading. There is no need for developers to do anything special beyond enabling this feature.

And again, it's super comfy to enable Event Replay in your app 🤩

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(
      withEventReplay(), // use hydration with v18 event replay
    ),
  ],
};

Note: At the time of writing, this feature is still in Developer Preview, so use it cautiously. However, I believe it's perfectly ready for production usage.

Hybrid Rendering (in preview since v19)

Angular v19 will introduce Hybrid Rendering to meet modern web demands following this RFC in the Angular GitHup repo. It allows providing additional route information for the server. Details like rendering modes and response headers will provide finer control for SSR.

We can now select the page rendering mode per route:

SSR: The page renders on the server during a request (best for dynamic content that updates quickly)
SSG: The page renders during build time and is served as a static asset (best for UX & performance)
CSR: The page renders in the browser (best for user-based content)

To do this we need to add a serverConfig in app.config.server.ts looking like this:

/* src/app/app.config.server.ts */
// imports [...]

const serverAppConfig: ApplicationConfig = {
  providers: [provideServerRendering(), provideServerRoutesConfig(serverRoutes)],
};

export const serverConfig = mergeApplicationConfig(appConfig, serverAppConfig);

This will be used in our main.server.ts instead of the client appConfig:

/* src/main.server.ts */
// imports [...]

const bootstrap = () => bootstrapApplication(AppComponent, serverConfig);

export default bootstrap;

Next, we can specify the renderMode for each serverRoute:

/* src/app/app.routes.server.ts */
// imports [...]

export const serverRoutes: ServerRoute[] = [
  { path: "ssr", renderMode: RenderMode.Server },
  { path: "ssg", renderMode: RenderMode.Prerender },
  { path: "csr", renderMode: RenderMode.Client },
];

Note: The same routes need to be used in app.routes.ts to become fully functional.

Additionally, some intelligent features like server side 301 redirects or 404 not found errors can be added to the server config.

/* src/app/app.routes.server.ts */
// imports [...]

export const serverRoutes: ServerRoute[] = [
  // [...],
  { path: "redirect", renderMode: RenderMode.Server, status: 301 },
  {
    path: "error",
    renderMode: RenderMode.Server,
    status: 404,
    headers: {
      "Cache-Control": "no-cache",
    },
  },
  { path: "**", renderMode: RenderMode.Server },
];

If you want to play around with this, check out this v19-ssr demo by ma man Matthieu Riegler.

Note: At the time of writing, this feature is still in Developer Preview, so implement it cautiously as the API may still change.

Incremental Hydration (in preview since v19)

Partial Hydration, now called Incremental Hydration, announced at ng-conf and Google I/O 2024, is a technique that allows incremental hydration of an app after server-side rendering, improving the initial load but also runtime performance by loading less JavaScript upfront. It builds upon the fabulous @defer API, in which we all fell in love since Angular v17. It's enabling Angular to render the HTML content on the server and hydrate deferred blocks on the client after they have been triggered to do so.

The Angular team (special thanks goes out to Jessica Janiuk! By the way, watch here presenation of Incremental Hydration in Angular v19 on YouTube) completed the RFC in the Angular GitHup repo and is now actively prototyping this feature, with an experimental release in v19 for all performance-critical applications out there 🥳

To test it simply add withIncrementalHydration() to your app.config.ts:

import { provideClientHydration, withIncrementalHydration } from "@angular/platform-browser";

export const appConfig: ApplicationConfig = {
  providers: [
    // [...]
    provideClientHydration(withIncrementalHydration()),
  ],
};

Please note: Event Replay is automatically enabled when using withIncrementalHydration(), so you can remove that provider.

Next, you can set a Hydration Trigger by choosing either:

hydrate on with a trigger (same as for @defer, see here for a full list of built-in triggers)
hydrate when with a boolean symbol, Signal or function as the trigger
hydrate never component will get rendered on the server but never hydrated (for static content)

hydrate on

@defer (on viewport; prefetch on idle; hydrate on hover) {
  <app-deferred-hydration />
}

The component's static and SSRed HTML will be rendered before coming into the viewport, the corresponding JS bundle will be prefetched on idle (like PreloadingStrategy in the Router) and then finally the JS (all the interactivity, like event handlers) will be hydrated into the browser on hover. This is in stark contrast to the default full-application hydration, where all the components are hydrated at once.

hydrate when

@defer (hydrate when isUserLoggedIn) {
  <app-deferred-hydration />
}

The component will be rendered on idle (default @defer trigger), i.e. after bootstrapping the App is complete, but it will only be hydrated once isUserLoggedIn is true.

hydrate never

@defer (on viewport; hydrate never) {
  <app-deferred-hydration />
}

The component will be rendered on viewport, but it will never be hydrated - so no event handlers will be attached.

Incremental Hydration Demo

Make sure to play around with this fun-tastic feature starting from my Incremental Hydration Demo on GitHub 😏

Give back some love

Since this feature is still in experimental make sure to help further improve it by providing useful feedback to the RFC in the Angular GitHup repo.

Build

Since Angular v17 we have two options for building our Angular app.

Angular's new Application Builder (all-in-one)

As mentioned, I'd recommend switching to the new Application Builder using esbuild and Vite. The advantage of using esbuild over Webpack is that it offers faster build times and more efficient and fine-grained bundling. The significantly smaller bundle also leads to better initial load performance – with or without SSR! Vite is a faster development server supporting extremely fast Hot Module Replacement (HMR).

Additionally, both SSR and Prerendering (SSG) are enabled by default as mentioned in this screenshot from the Angular Docs showing a table of the Angular Builders (note that the @angular-devkit/build-angular:server is missing here):

Simply run ng b to trigger a browser and server build in one step. Angular will automatically process the Router configuration(s) to find all unparameterized routes and prerender them for you. If you want, you can add parameterized routes via a txt file. To migrate, read my automated App Builder migration guide.

If still using Webpack (for reasons)

If – for any reason – you're still committed to using Webpack to build your web app, you need the browser builder to be configured in your angular.json (might be in project.json if you're using Nx). This will, of course, be added automatically once you run ng add @angular/ssr.

{
  "server": {
    "builder": "@angular-devkit/build-angular:server",
    "options": {
      "outputPath": "dist/your-fancy-app-name/server",
      "main": "server.ts",
      "tsConfig": "tsconfig.server.json"
    }
  }
}

Note: The referenced server.ts lies in the project's root and is the entry point of your server application. With this dedicated server builder, there is also a dedicated tsconfig.server.json (whereas the new Application Builder recommended previously merges the two tsconfig files for more convenience) 🤓

Now let's quickly have a look at the build scripts:

Important note: If you haven't started using pnpm, you're missing out. However, of course, both npm run ... and yarn ... will also work instead of pnpm ....

pnpm dev:ssr
ng run your-fancy-app-name:serve-ssr

Similar to ng s, which offers live reload during development, but uses server-side rendering. Altogether, it's a bit slower than ng s and won't be used a lot apart from quickly testing SSR on localhost.

pnpm build:ssr
ng build && ng run your-fancy-app-name:server

Builds both the browser application and the server script in production mode into the dist folder. Use this command when you want to build the project for deployment or run performance tests. For the latter, you could use serve or a similar tool to serve the application on your localhost.

Deploy

You have two options for deployment. While both are technically possible, I'd recommend using the second one.

Using on-demand rendering mode via node server

Starts the server for serving the application with node using SSR.

pnpm serve:ssr
node dist/your-fancy-app-name/server/main.js

I've shown a detailed example Docker container here.

Caution: Angular requires a certain Node.js version to run, for details see the Angular version compatibility matrix.

Using build time SSR with SSG (recommended)

This option doesn't need a node environment on the server and is also way faster than the other one.

pnpm prerender
ng run your-fancy-app-name:prerender

Used to generate an application's prerendered routes. The static HTML files of the prerendered routes will be attached to the browser build, not the server. Now you can deploy your browser build to whatever host you want (e.g. nginx). You're doing the same thing as without SSR with some extra directories (and index.html files).

Important note: If you're using the new (and recommended) Application Builder, you can skip these steps for building and prerendering since they're already included in ng b. In other words, you have zero extra work for building including SSR & SSG – pretty great, huh? 😎

Debug

The first step in debugging is looking for misconfigurations in your angular.json (project.json) or some errors in your server.ts. If both look good, there is no definite way to debug SSR and SSG issues. Feel free to contact me if you're experiencing any troubles.

How to avoid the most common issue

Browser-specific objects like document, window, localStorage, etc., do NOT exist on the server app. Since these objects are not available in a Node.js environment, trying to access them results in errors. This can be avoided by using the document injector or by running code explicitly in the browser:

import { Component, inject, PLATFORM_ID } from "@angular/core";
import { DOCUMENT, isPlatformBrowser, isPlatformServer } from "@angular/common";

export class AppComponent {
  private readonly platform = inject(PLATFORM_ID);
  private readonly document = inject(DOCUMENT);

  constructor() {
    if (isPlatformBrowser(this.platform)) {
      console.warn("browser");
      // Safe to use document, window, localStorage, etc. :-)
      console.log(document);
    }

    if (isPlatformServer(this.platform)) {
      console.warn("server");
      // Not smart to use document here, however, we can inject it ;-)
      console.log(this.document);
    }
  }
}

Browser-Exclusive Render Hooks

An alternative to injecting isPlatformBrowser are the two render hooks afterNextRender and afterRender, which can only be used within the injection context (basically field initializers or the constructor of a component):

The afterNextRender hook, takes a callback function that runs once after the next change detection – a bit similar to the init lifecycle hooks. It's used for performing one-time initializations, such as integrating 3party libs or utilizing browser APIs:

export class MyBrowserComponent {
  constructor() {
    afterNextRender(() => {
      console.log("hello my friend!");
    });
  }
}

If you want to use this outside of the injection context, you'll have to add the injector:

export class MyBrowserComponent {
  private readonly injector = inject(Injector);

  onClick(): void {
    afterNextRender(
      () => {
        console.log("you've just clicked!");
      },
      { injector: this.injector },
    );
  }
}

The afterRender hook, instead, is executed after every upcoming change detection. So use it with extra caution – same as you would do with the ngDoCheck and ng[Content|View]Checked hooks because we know that Change Detection will be triggered a lot in our Angular app – at least until we go zoneless, but that story that will be presented in yet another blog post 😎

export class MyBrowserComponent {
  constructor() {
    afterRender(() => {
      console.log("cd just finished work!");
    });
  }
}

If you'd like to deep dive into these hooks, I recommend reading this blog post by Netanel Basal.

Angular Hydration in DevTools

The awesome Angular collaborator Matthieu Riegler has recently added hydration debugging support to the Angular's DevTools! Which are, besides all Chromium derivatives, also available for Firefox, but then why would somebody still use that Boomer browser? 😏

Note the 💧 for hydrated components. Even though this feature was announced in the Angular v18 update, it also works in past versions.

Other SSR Debugging Best Practices

Here is a collection of some more opinionated debugging recommendations:

DevTools: Besides the updated Angular DevTools tab, inspect your HTML with the Elements tab and your API requests with the Network tab. BTW, you should also simulate a slow connection here when performance testing your app.
Console: I personally like to log everything into my Console. Not interested in a logger lib since I'm fine with console.log() and maybe some other levels. Any console logs will be printed into the terminal where ng b or pnpm dev:ssr or pnpm serve:ssr has been run. We don't need to talk about logging into the browser's console on production, or do we?
Node.js: Start your SSR server with the --inspect flag to get more information: node --inspect dist/server/main.js
Fetching: Ensure all necessary data is available at render time. Use Angular's TransferState to transfer data from the server to the client.
Routing: Make sure all routes are correctly configured and match on both the browser and server builds.
Environments: Ensure environment variables are correctly set up for both browser and server builds.
3rd-party Libs: As always, be very careful about what you include in your project. Some libraries might not be implemented correctly and thus not work in an SSR context. Use conditional imports or platform checks to handle these cases or, even better, get rid of those libs in the first place.

That's all I have got so far. If you've got anything to add, feel super free to contact me!

Advanced

Disable Hydration for Components

Some components may not work properly with hydration enabled due to some issues, like DOM Manipulation. As a workaround, you can add the ngSkipHydration attribute to a component's tag to skip hydrating the entire component.

<app-example ngSkipHydration />

Alternatively, you can set ngSkipHydration as a host binding.

@Component({
  host: { ngSkipHydration: "true" },
})
class DryComponent {}

Please use this carefully and thoughtfully. It is intended as a last-resort workaround. Components that have to skip hydration should be considered bugs that need to be fixed.

Use Fetch API instead of XHR

The Fetch API offers a modern, promise-based approach to making HTTP requests, providing a cleaner and more readable syntax compared to the well-aged XMLHttpRequest. Additionally, it provides better error handling and more powerful features such as support for streaming responses and configurable request options. It's also recommended to be used with SSR by the Angular team.

To enable it, simply add withFetch() to your provideHttpClient():

export const appConfig: ApplicationConfig = {
  providers: [provideHttpClient(withFetch())],
};

If you're still using NgModules (for reasons), this becomes:

@NgModule({
  providers: [provideHttpClient(withFetch())],
})
export class AppModule {}

Configure SSR API Request Cache

The Angular HttpClient will cache all outgoing network requests when running on the server. The responses are serialized and transferred to the browser as part of the server-side HTML. In the browser, HttpClient checks whether it has data in the cache and if so, reuses that instead of making a new HTTP request during the initial load. HttpClient stops using the cache once an application becomes stable in the browser.

By default, HttpClient caches all HEAD and GET requests that don't contain Authorization or Proxy-Authorization headers. You can override those settings by using withHttpTransferCacheOptions when providing hydration:

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(
      withEventReplay(),
      withHttpTransferCacheOptions({
        filter: (req: HttpRequest<unknown>) => true, // to filter
        includeHeaders: [], // to include headers
        includePostRequests: true, // to include POST
        includeRequestsWithAuthHeaders: false, // to include with auth
      }),
    ),
  ],
};

Use Hydration support in Material 18 and CDK 18 💧

Starting with Angular Material 18, all components and primitives are fully SSR and Hydration compatible. For information, read this blog post. On how to upgrade your Angular Material app, consult the docs on migrate from Material 2 to Material 3.

Combine SSR for static & CSR for user content 🤯

As already mentioned above, with Angular v17 Deferrable Views you can easily mix SSR/SSG with CSR 🎉

The usage is pretty straightforward: All @defer components will render their @placeholder on the server and the real content will be loaded and rendered once they have been triggered (by on or when) in the browser. Learn more about how to use and trigger Deferrable Views.

Here are some primitive examples of how to combine SSR and CSR:

Static pages: Use SSR (SSG)
Static content with live updates: Use deferred components for the live content and SSR for the rest
Product list with prices depending on the user: Defer price components and use SSR for the rest
List with items depending on the user: Defer the list component and use SSR for the rest

So basically, everywhere you need CSR (for user-dependent content), you need to @defer those parts. Use the @placeholder (and @loading) to show spinners or equivalents to inform the user that something is still being loaded. Also, make sure to reserve the right amount of space for the deferred components – avoid layout shifts at all costs!

SEO and Social Media Crawling 🔍

If you want to look good on Google and/or social media platforms, make sure to implement all the necessary meta tags in SSR. For a comprehensive list, including some tools and tips, jump here.

export class SeoComponent {
  private readonly title = inject(Title);
  private readonly meta = inject(Meta);

  constructor() {
    // set SEO metadata
    this.title.setTitle("My fancy page/route title. Ideal length 60-70 chars");
    this.meta.addTag({ name: "description", content: "My fancy meta description. Ideal length 120-150 characters." });
  }
}

Use SSR & SSG within AnalogJS 🚀

AnalogJS is the meta-framework built on top of Angular – like Next.js (React), Nuxt (VueJS), SolidStart (Solid). Analog supports SSR during development and building for production. If you want to know more, read the announcement of version 1.0 by Brandon Roberts or wait for my upcoming blog post 😏

Angular SSR & SSG featuring I18n

Since the Angular I18n only works during built-time, it's fairly limited. Therefore, we recommend using Transloco (or NGX-Translate). When adding Transloco by running ng add @jsverse/transloco, you'll be prompted for SSR usage. However, you can also manually add the necessary changes for SSR (see Transloco Docs):

@Injectable({ providedIn: "root" })
export class TranslocoHttpLoader implements TranslocoLoader {
  private readonly http = inject(HttpClient);

  getTranslation(lang: string) {
    return this.http.get<Translation>(`${environment.baseUrl}/assets/i18n/${lang}.json`);
  }
}

export const environment = {
  production: false,
  baseUrl: "http://localhost:4200", // <== provide base URL for each env
};

This will SSR everything in the default language and then switch to the user's language (if different) in the browser. While this generally works, it's definitely not ideal to see the text being swapped. Furthermore, we need to ensure there are no layout shifts upon switching! If you come up with any ideas on how to improve this, please contact me!

SSR and Hydration with Native Federation

The Angular Architects' native federation package now finally supports SSR for the shell app (starting with v18.2.3). This allows you to use Module Federation together with SSR and SSG in your Angular app. Native Federation has the same API as the webpack Module Federation but uses browser-native Import Maps and is thus also working with esbuild – Angular's new Application Builder.

Learn more about this approach and how to get started in this post by the master of module federation Manfred Steyer.

Caution with PWA

Be careful if you are using Angular SSR in combination with the Angular PWA service worker because the behavior deviates from default SSR. The initial request will be server-side rendered as expected. However, subsequent requests are handled by the service worker and thus client-side rendered.

Most of the time that's what you want. Nevertheless, if you want a fresh request you can use the freshness option as Angular PWA navigationRequestStrategy. This approach will try a network request and fall back to the cached version of index.html when offline. For more information, consult the Angular Docs and read this response on Stack Overflow.

Outlook

The next step will be streamed SSR for zoneless apps. To see what’s planned for upcoming Angular releases, check the roadmap:

Angular roadmap on angular.dev

Performance Workshop

If you want to deep dive into Angular, we offer a variety of workshops – both in English and German.

Performance Workshop 🚀
Best Practices Workshop 📈 (including performance related topics)
Accessibility Workshop ♿

Conclusion

In summary, implementing Server-Side Rendering (SSR) in Angular — along with Static Site Generation (SSG), hydration, and event replay — significantly enhances the initial load performance of your Angular applications. With the new Incremental Hydration feature, Angular has taken a significant step toward becoming the framework of choice for building high-performance web applications – something it has not traditionally been known for.

This advancement results in a better user experience, particularly on slower networks or less capable devices, and it also improves your web app’s SEO and crawlability. By following the guidelines and best practices outlined in this guide, you can boost your apps’ load performance with minimal effort. Furthermore, the new Application Builder simplifies the process of building and deploying your projects.

Feel free to contact me for further questions or join our Performance Workshop 🚀 or the Best Practices Workshop 📈to learn more about performance optimization for Angular apps.

This blog post was written by Alexander Thalhammer. Follow me on GitHub, X or LinkedIn.

References

Why is Initial Load Performance so Important? by Alexander Thalhammer
Angular v16 – official blog post by Minko Gechev
Angular Update Guide to V17 incl. migrations by Alexander Thalhammer
Angular v17’s Deferrable Views by Alexander Thalhammer
Angular v18 – official blog post by Minko Gechev
Angular’s after(Next)Render hooks by Netanel Basal
Angular Event Replay blog post by Jatin Ramanathan & Tom Wilkinson
Angular Incremental Hydration on YouTube by Jessica Janiuk
Angular SSR Docker example by Alexander Thalhammer

DEV Community: Alexander Thalhammer

Why Angular ARIA in v21 is pretty neat

Components

Why is this neat?

When to use Angular ARIA?

When to avoid Angular ARIA?

Angular Styling Best Choices Matrix

Workshops

Conclusion

Enhancing A11y with Angular CDK

LiveAnnouncer for Screen Readers

Focus Tools

Focus Trap

Focus Regions

Focus Monitor

Styling utilities

Hidden Elements

High Contrast Mode

Accessibility Workshop

Conclusion

That's all folks!

References

Building Accessible Forms with Angular

Angular Forms

Keyboard Navigation & Tab Focus

Form Fields

Labels & type attribute

Grouping fields

Required fields

Autocomplete

ARIA attributes

Error messages

Accessibility Workshop

Conclusion

ARIA roles and attributes in Angular

About ARIA

ARIA in Angular

ARIA vs. Semantic HTML

ARIA Roles

Most commonly used ARIA roles

Examples

ARIA Attributes

Most commonly used ARIA attributes

Widget attributes (states and properties)

Live region attributes (states)

Drag-and-Drop attributes (states)

Relationship attributes (properties)

Examples

Accessibility Workshop

Conclusion

References

Accessible Angular Routes

Page Titles

Route.title

Global Page Title Strategy

Dynamic Page Titles using Angular Router Params

All Together Now

RouterLinkActive

Fine-tuned control with routerLinkActiveOptions

Indicate current page ariaCurrentWhenActive

Accessibility Workshop

Conclusion

References

Accessibility Testing Tools for Angular

Introduction

Chromium Browser

Chromium Extensions

Automated Testing

Identify issues and how to know what to fix

Angular ESLint (only for Angular apps)

WAVE Chrome Extension

WAVE Web Service

Axe Chrome Dev Tools

Lighthouse Dev Tools

PageSpeed Insights Web Service

Accessibility Insights Dev Tools

Run A11y Tests

Manual (Auditory) Testing

Screen Reader

Accessibility Workshop

Fine-tuned control with `routerLinkActiveOptions`

Indicate current page `ariaCurrentWhenActive`