Week 22: Animations, Accessibility & Internationalization

1. Angular Animations API & CSS-Driven Alternatives

Angular's animation package gives you programmatic control over enter/leave transitions triggered by state changes — useful when a transition needs to know about component state, not just a CSS class.

import { Component, input } from '@angular/core';
import { trigger, transition, style, animate } from '@angular/animations';

@Component({
  selector: 'app-notification-toast',
  templateUrl: './notification-toast.html',
  animations: [
    trigger('slideIn', [
      transition(':enter', [
        style({ transform: 'translateY(-16px)', opacity: 0 }),
        animate('200ms ease-out', style({ transform: 'translateY(0)', opacity: 1 })),
      ]),
      transition(':leave', [
        animate('150ms ease-in', style({ transform: 'translateY(-16px)', opacity: 0 })),
      ]),
    ]),
  ],
})
export class NotificationToast {
  message = input.required<string>();
}

For simpler cases — a hover effect, a straightforward fade — plain CSS transitions often do the same job with less code and no extra bundle weight from the animations package at all:

.card {
  transition: transform 0.2s ease, box-shadow 0.2s ease;
}

.card:hover {
  transform: translateY(-4px);
  box-shadow: var(--shadow-lg);
}

Reach for the animations API specifically when a transition needs to react to Angular-level state (a signal changing, an element actually entering/leaving the DOM via @if) — reach for plain CSS for anything driven purely by user interaction like :hover or :focus.

2. Reduced-Motion Support

Some users experience genuine discomfort or disorientation from motion — the prefers-reduced-motion media query lets you respect that operating-system level preference directly.

@media (prefers-reduced-motion: reduce) {
  .card {
    transition: none;
  }
}

const prefersReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;

if (!prefersReducedMotion) {
  // only run the toast slide-in animation, confetti, parallax scroll, etc.
}

This isn't a nice-to-have layered on top of accessibility — it's an accessibility requirement in its own right, and one of the easiest to actually implement correctly once you know it exists.

3. WCAG Basics & Accessible Component Patterns

WCAG (Web Content Accessibility Guidelines) organizes accessibility around four principles, worth knowing by name: content must be Perceivable, Operable, Understandable, and Robust. A few concrete, high-impact patterns that follow from them:

• Every interactive element needs an accessible name — visible text, or aria-label when there's no visible text (an icon-only button).
• Color alone should never be the only way information is conveyed — an error state needs an icon or text, not just red.
• Custom components mimicking native ones (a custom dropdown, a custom checkbox) need the matching ARIA role and keyboard behavior — or you're better off starting from the real native element and styling it.

<button aria-label="Delete item" (click)="delete()">
  <svg aria-hidden="true">...</svg>
</button>

aria-hidden="true" on the icon prevents assistive technology from announcing the SVG's raw contents redundantly — the button's aria-label already says everything that needs saying.

4. Keyboard Navigation & Focus Management

A keyboard-only user navigates entirely via Tab, Shift+Tab, Enter, and arrow keys — no mouse at all. You already used the CDK's cdkTrapFocus for this back in Week 7; this section is the broader pattern it's part of.

import { Component, ElementRef, viewChild, effect } from '@angular/core';

export class Modal {
  private closeButton = viewChild<ElementRef<HTMLButtonElement>>('closeBtn');
  open = model(false);

  constructor() {
    effect(() => {
      if (this.open()) {
        // Move focus INTO the modal the moment it opens
        this.closeButton()?.nativeElement.focus();
      }
    });
  }
}

Two rules cover most focus-management needs: when a modal or menu opens, move focus into it (usually to the first focusable element or a close button); when it closes, move focus back to whatever element opened it. Without the second rule, a keyboard user's focus silently lands on <body> after closing a dialog, and they have to start tabbing from the top of the page again.

5. Angular i18n & Runtime Translation Strategies

Angular's built-in @angular/localize is a build-time approach — it produces a separate compiled build per locale, which is fast at runtime but means deploying multiple builds.

<h1 i18n="@@welcomeHeading">Welcome back, {{ user().name }}</h1>

ng extract-i18n   # generates a translation source file (messages.xlf)
ng build --localize   # builds one output per configured locale

The alternative — a runtime translation library (like ngx-translate) — loads translation JSON dynamically and switches language without a rebuild or page reload, at the cost of a small runtime overhead and translations that aren't statically checked at build time. Build-time i18n fits an app with a small, known set of locales; runtime fits an app where users switch language on the fly, or locales are added without a full redeploy.

6. Auditing an App with Lighthouse/axe

Automated tools catch a meaningful subset of accessibility issues — not everything (real screen-reader testing and manual keyboard testing still matter), but enough to be worth running on every significant change.

npx @axe-core/cli http://localhost:4200

Chrome DevTools' Lighthouse panel runs a broader audit — accessibility, performance (tying back to Week 20), best practices, and SEO — each producing a scored report with specific, actionable findings rather than a vague pass/fail.

7. Hands-on Exercise

8. Knowledge Check

Four quick questions. Expand each to check your answer.