What is an AXEvent?

Published: 5 December 2025

An AXEvent is a notification generated by the browser when something meaningful changes in the accessibility tree and needs to be communicated to assistive technologies.

Note: “AXEvent” is Chrome’s internal term. WebKit and Firefox use different names, but the underlying concept is the same: an accessibility event fired when the AXTree changes in a meaningful way.

An AXEvent is like the browser telling the screen reader:

“Something important just changed.”

Why AXEvents exist

These events keep assistive technologies in sync with what’s happening on the page.

Screen readers do not continually poll or scan the entire interface — that would be slow and wasteful.

Instead, browsers emit AXEvents only when an accessibility-relevant change occurs.

This makes assistive technologies faster, more responsive, and less noisy.

Where AXEvents come from

AXEvents do not come from your HTML directly. They come from changes in the browser’s accessibility tree (AXTree).

The AXTree is a separate structure derived from the DOM. It is not a 1:1 copy. Some DOM elements are ignored entirely, while others expand into many accessibility nodes.

Whenever the DOM changes in a meaningful way — with or without JavaScript — the browser may recompute affected regions of the AXTree.

If an accessibility-relevant property changes (name, value, focus, state, or role), the browser compares the old and new AXTree state and fires one or more AXEvents.

Note: Browsers may batch or defer AXTree recomputation for performance. AXEvents fire after the AXTree is stable and the change is determined to be significant.

Examples of AXEvents

Here are some common accessibility changes that cause AXEvents:

Changes to focus

• Moving focus to a button.
• Tabbing into a form field.
• Using arrow keys in a menu.

Changes to value

• Typing into an <input>.
• Selecting an item in a dropdown.
• Adjusting a slider.

Changes to state

• Opening or closing a disclosure widget.
• Checking a checkbox or radio button.
• Showing or hiding an error message.
• Enabling or disabling a button.

Changes to name or description

• Updating visible text used as a label.
• Updating a live region.

Where AXEvents go

After AXEvents are generated, the browser sends them to the operating system’s accessibility API:

• AX API — macOS and iOS
• UIA — Windows
• ATK / AT-SPI — Linux

From there, the OS delivers the events to assistive technologies such as VoiceOver, NVDA, and JAWS.

What screen readers do with AXEvents

Screen readers do not announce everything they receive. They apply their own logic, rules, verbosity settings, and timing heuristics.

Screen readers might do any of the following:

• Announce the change immediately.
• Queue it behind other messages.
• Merge it with related events.
• Interrupt what is currently speaking.
• Ignore it entirely.

This explains why different screen readers may behave differently even when receiving the same information.

The process

DOM Mutation
     │
     ▼
Accessibility Tree Update
     │
     ▼
AXEvent Fired
     │
     ▼
OS Accessibility API
     │
     ▼
Assistive Technology
     │
     ▼
Speech / Braille Output

Summary

Understanding AXEvents helps clarify:

• Why some changes are announced and others are not.
• Why announcements differ across browsers and platforms.
• Why invisible DOM updates still affect screen reader output.
• Why live region behaviour varies across AT.

AXEvents are the key signals that keep the browser and assistive technologies aligned.