Accessibility (a11y) in Angular

Q: What is accessibility in Angular and why does it matter?

Accessibility means building an app that everyone can use, including people who use screen readers, keyboards only, or have vision or motor difficulties. In Angular this means using semantic HTML elements, adding proper labels to form fields, and making sure every interactive element can be reached and used with a keyboard.

Q: How does Angular CDK's a11y package help improve accessibility in an app?

The Angular CDK includes a dedicated a11y package with tools like FocusTrap, which keeps keyboard focus inside a dialog while it is open, and LiveAnnouncer, which lets you announce dynamic messages to screen reader users that would otherwise go unnoticed.

Q: How do you add ARIA attributes to a custom Angular component to make it accessible?

You bind ARIA attributes directly in the component template using Angular's attribute binding syntax, describing the role and current state of a custom element so a screen reader can correctly announce it, especially when a native HTML element does not already provide that meaning on its own.

Q: How would you manage keyboard focus properly in an Angular modal dialog to keep it accessible?

When a modal opens, focus should move into the modal automatically, and it should stay trapped inside the modal while it is open so a keyboard user cannot accidentally tab to content behind it. The Angular CDK's FocusTrap directive handles this trapping automatically, and you can move focus back to the triggering element when the modal closes.

Q: What tools can you use to check accessibility issues in an Angular app?

The Angular ESLint plugin can catch some accessibility mistakes right inside your code editor while you type. The axe DevTools browser extension and Lighthouse in Chrome scan a running page and list real accessibility problems along with clear suggestions on how to fix each one.

5 questions found

What is accessibility in Angular and why does it matter?

Beginner

Accessibility means building an app that everyone can use, including people who use screen readers, keyboards only, or have vision or motor difficulties. In Angular this means using semantic HTML elements, adding proper labels to form fields, and making sure every interactive element can be reached and used with a keyboard.

@Component({
  selector: 'app-login',
  template: `
    <label for="email">Email</label>
    <input id="email" type="email" name="email" />
    <button type="submit">Log In</button>
  `
})
export class LoginComponent {}

Real-world example A banking website adds proper labels and keyboard support to every form so that a visually impaired customer using a screen reader can open an account without needing help from anyone else.

Common follow-ups: What happens if a form input has no label at all?;How do you test an Angular app for accessibility issues?

Forms;Components & Templates

How does Angular CDK's a11y package help improve accessibility in an app?

Intermediate

The Angular CDK includes a dedicated a11y package with tools like FocusTrap, which keeps keyboard focus inside a dialog while it is open, and LiveAnnouncer, which lets you announce dynamic messages to screen reader users that would otherwise go unnoticed.

import { LiveAnnouncer } from '@angular/cdk/a11y';

constructor(private liveAnnouncer: LiveAnnouncer) {}

saveForm() {
  this.liveAnnouncer.announce('Your changes have been saved');
}

Real-world example A settings page announces a clear confirmation message using LiveAnnouncer whenever a user saves a change, so screen reader users know their action succeeded even though nothing visually dramatic happened on screen.

Common follow-ups: How does FocusTrap prevent a keyboard user from tabbing outside an open dialog?;What other accessibility helpers does the Angular CDK provide?

Angular CDK (Component Dev Kit);Angular Material & UI Component Libraries

How do you add ARIA attributes to a custom Angular component to make it accessible?

Intermediate

You bind ARIA attributes directly in the component template using Angular's attribute binding syntax, describing the role and current state of a custom element so a screen reader can correctly announce it, especially when a native HTML element does not already provide that meaning on its own.

@Component({
  selector: 'app-menu-button',
  template: `
    <button [attr.aria-expanded]="isOpen" aria-label="Open navigation menu" (click)="toggle()">
      Menu
    </button>
  `
})
export class MenuButtonComponent {
  isOpen = false;
  toggle() { this.isOpen = !this.isOpen; }
}

Real-world example A shopping app adds an aria expanded attribute to its dropdown filter button so screen reader users know whether the filter options are currently showing or hidden.

Common follow-ups: When should you avoid using ARIA attributes instead of native HTML elements?;What is the difference between aria label and aria labelledby?

Components & Templates;Data Binding

How would you manage keyboard focus properly in an Angular modal dialog to keep it accessible?

Advanced

When a modal opens, focus should move into the modal automatically, and it should stay trapped inside the modal while it is open so a keyboard user cannot accidentally tab to content behind it. The Angular CDK's FocusTrap directive handles this trapping automatically, and you can move focus back to the triggering element when the modal closes.

import { FocusTrapFactory } from '@angular/cdk/a11y';

@Component({
  selector: 'app-modal',
  template: `<div cdkTrapFocus><ng-content></ng-content></div>`
})
export class ModalComponent {}

Real-world example A checkout page traps keyboard focus inside its payment confirmation modal using the cdkTrapFocus directive, so a user pressing Tab repeatedly stays inside the dialog instead of jumping back to the page behind it.

Common follow-ups: What happens to focus when the modal closes, and how do you restore it correctly?;What ARIA role and attributes are expected on a modal dialog?

Angular CDK (Component Dev Kit);Directives

What tools can you use to check accessibility issues in an Angular app?

Beginner

The Angular ESLint plugin can catch some accessibility mistakes right inside your code editor while you type. The axe DevTools browser extension and Lighthouse in Chrome scan a running page and list real accessibility problems along with clear suggestions on how to fix each one.

// Running Lighthouse from the command line
npx lighthouse http://localhost:4200 --view

// Reports accessibility issues like missing labels, low contrast text, and more

Real-world example A team runs Lighthouse against their Angular app before every release, catching missing alt text on images and low color contrast issues before real users ever encounter them.

Common follow-ups: How does automated accessibility testing differ from testing with a real screen reader?;What accessibility score does Lighthouse usually flag first for a new Angular project?

Testing with Jasmine & Karma;Angular DevTools & Debugging