JavaScript · Advanced level

Advanced level · Module 5: Performance, Security and Accessibility in JavaScript · Lesson 4 of 4

Accessible Dynamic Interfaces

Make interfaces that change without reloading usable with a keyboard and screen readers.

In this lesson you will

  • Manage focus after dynamic changes
  • Announce status updates with ARIA live regions

Key concepts

semantic HTMLkeyboard accessfocus managementaria-live

The lesson

Start with semantic HTML: real <button> and <a> elements are focusable and keyboard-operable for free, while a clickable <div> is not. Every control needs a visible label.

When content changes — a dialog opens, a screen changes, an item is deleted — move focus somewhere sensible, such as the new screen's heading, so keyboard and screen-reader users are not left behind.

Status messages such as 'Visit saved' or 'Offline — 3 visits waiting to sync' should be placed in an aria-live="polite" region so screen readers announce them without moving focus.

Step by step

  1. Complete the whole app using only the keyboard and list the problems.
  2. Replace clickable divs with buttons.
  3. Move focus to the heading after route changes.
  4. Add a live region for sync status and test with a screen reader.

Practice activity

Make the visit tracker fully keyboard-accessible and announce sync status changes.

Expected result: Every task can be completed by keyboard and the screen reader announces status changes.

Check your understanding

  1. Why use <button> instead of a clickable <div>?

    Show answer

    Buttons are focusable and work with the keyboard and assistive technology by default.

  2. What does aria-live="polite" do?

    Show answer

    Announces changes to the region's content when the screen reader is idle.

Taught live by an instructor — online or in person. Free course lessons are for self-study and do not lead to a certificate — see registration options.