The DOM is a tree-like structure that shows all the elements in your HTML document.
It is live", which means it reacts to changes. It is not a passive version of your HTML.
"DOM mutations" are any changes that happen to this tree. These mutations can happen with or without JavaScript.
Browsers constantl check and modify the DOM to reflect things like:
- state changes — e.g. a checkbox becoming checked, a
<details>element becoming open. - attribute changes — e.g.
aria-expanded="false"switching to"true"when a disclosure widget opens. - user actions — e.g. typing into an
<input>updates its value property automatically. - validation results — e.g. a form control becoming
:invalidbecause of built-in browser validation (JavaScript not required). - interactive behaviour — e.g. a
<select>element updating which option is selected. - internal UI logic — e.g. the browser toggling the open attribute on
<details>when the summary is clicked. - accessibility behaviours (rare) — e.g. the browser inserting a computed accessible name into the AXTree when a label changes.
- parsing corrections — e.g. the browser inserting missing closing tags or restructuring malformed HTML.
- autofill — e.g. the browser writing values into
<input>fields during autofill. - spellchecking behaviour — e.g. the browser wrapping misspelled words in internal DOM markers for underlining.
None of these modifications need to be made using JavaScript. Many HTML elements have built-in behaviours. This means that browsers have to update the DOM to keep a range of things "in sync". This includes the element’s internal state, visual UI, and accessibility information.
Here are some quick examples you can try yourself:
- When you type into an
<input>, the browser updates the element’s value property. - When you select an option in a
<select>, the DOM automatically updates which option is selected. - When a
<details>element opens, the browser sets the open attribute on the<details>element automatically.
JavaScript and the DOM
JavaScript can also be used for DOM mutations.
When your script runs, it can directly change the structure, text, or attributes of elements — and every one of these changes counts as a DOM mutation.
Typical JavaScript-driven mutations include:
- Adding nodes — inserting new elements into the DOM, such as adding an error message or appending a list item.
- Removing nodes — deleting elements from the DOM, such as removing a modal, clearing a list, or hiding elements by removing them entirely.
- Updating attributes (including ARIA) — changing values like
aria-expanded, class,disabled, or value; every attribute update counts as a DOM mutation. - Changing text — modifying the textContent or innerText of an element, such as updating live status messages or replacing placeholder content.
- Changing internal state — refers to properties the browser tracks internally, such as whether a
<details>element is open, whether a form control is valid, or whether an element is focused.
These are sometimes called “JavaScript-driven DOM mutations” or “JS mutations”, but they are not really a special category — just another way the DOM changes.
Why DOM mutations matter for accessibility
Every DOM mutation means that browsers need to update the accessibility tree (AXTree). Screen readers and other assistive technologies use this tree.
Whenever the DOM changes:
- The browser updates the AXTree.
- It compares the old and new tree.
- It fires AXEvents 1 for anything meaningful that changed such as:
- Name changes
- Value changes
- Expanded/collapsed state
- Focus changes
- Role changes
- Live region updates
These AXEvents then travel through the operating system’s accessibility API to the screen reader, which interprets them and decides whether, when, and how to announce the change.
Not all AXEvents result in announcements — screen readers may merge, delay, or ignore certain events based on their behaviour and user settings.
If we return to our previous three examples, we can see that they all push information into the AXTree:
- The
<input>value is exposed as the control’s value - The
<select>option is exposed as the element’s accessible value - The
<summary>open/closed state is mapped to accessibility state
These updates happen because the browser does not keep a separate copy of your original HTML. Instead, it continuously updates accessibility information from the live, constantly changing DOM.
Why this matters
DOM mutations have a directly influence over the following:
- What screen readers announce.
- How quickly these announcements occur
- Which events interrupt others
- Whether changes are even detectable
Every DOM mutation means that browsers have to update accessibility information and fire accessibility events.
Wrapping up
- The DOM is not static.
- The browser performs DOM mutations frequently, even without JavaScript.
- JavaScript can also create DOM mutations.
- All DOM mutations flow into the AXTree.
- Accessibility updates, announcements, and timing are shaped by these mutations.
Related articles
What happens when an event occurs? — the quick answer
Ever wondered how a browser turns an interaction into a screen reader announcement?
What is an AXEvent?
Detailed explanation of AXevents.
What really happens when a user clicks an accordion button?
A more detailed explanation of an event.
End-to-end browser and accessibility event architecture
A full explanation of how browsers and assistive technologies communicate.
Footnotes
- [1] AX event: An accessibility event fired by the browser when something meaningful changes in the AXTree, such as focus, name, value, or state changes. [Back]