Implicit Live Values in status, alert, log, and timer Roles

Every ARIA role has a definition, and every definition lists default values for the states and properties the role supports. Those defaults are part of the role, not suggestions. Writing role="status" sets politeness to polite and atomicity to true on that element, in the tree, whether or not the author wrote either attribute. The consequence is that a live region’s behaviour is decided in two places, the role’s definition and the author’s attributes, and the two can disagree in ways that are silent in markup and audible in use.

Where the defaults come from

The ARIA specification defines each role with a table of supported states and properties, each with an implicit value. For the live roles the table reads, in the current specification:

• alert: aria-live="assertive", aria-atomic="true".
• status: aria-live="polite", aria-atomic="true".
• log: aria-live="polite", aria-atomic="false".
• marquee: aria-live="off".
• timer: aria-live="off".
• alertdialog: aria-live="assertive", aria-atomic="true", aria-modal="true".

The pattern in the numbers is the design. alert and status differ only in politeness, and both are atomic, because both are meant to be a single sentence that is replaced as a whole: “Saved”, “Connection lost”. log is polite and non-atomic, because a log grows by appending entries and each entry should be spoken as it arrives rather than the whole log being re-read. marquee and timer are explicitly not live, because their content changes continuously and continuously announcing a clock or a ticker would make the page unusable. Their roles exist so that the content is identifiable, not so that it is spoken.

The asymmetry that trips authors is atomicity. A status region whose contents are “Uploading 3 of 12 files” and then “Uploading 4 of 12 files” speaks the full string both times, because the implicit aria-atomic="true" makes the region the unit. A log with the same content appended line by line speaks only the new line. Authors who use role="log" for a status line and then cannot understand why the user hears fragments have hit the non-atomic default and never noticed it existed.

Author attributes override, including badly

An explicit attribute on the element wins over the role’s implicit value. role="alert" aria-live="polite" produces a polite region that the reader will not treat as an alert’s assertive announcement. This is intentional in the specification, where the implicit value is a default rather than a constraint, but the practical effect is a tree that says two things.

Three override patterns recur and each has a defect.

The first is role="alert" with aria-live="off". The author has created an element announced as an alert, with an assertive implicit value, and then disabled announcement entirely. The role’s semantics remain: the element still maps to an alert in the platform, and a reader that inspects the role may still treat its appearance as noteworthy. The result is neither an alert nor a silent container, and the author almost always meant to use a plain container with no role.

The second is role="alert" with aria-atomic="false". The role’s definition says atomic, and the author has overridden it. Behaviour now depends on which copy the reader consults: some readers apply the author value, some apply the role default, and the difference is whether the user hears “3 errors” or “3”. Since the point of the alert role is to make an announcement impossible to miss, the override is a way to make it partially missable.

The third is redundant declaration: role="status" aria-live="polite" aria-atomic="true". Nothing is wrong, and nothing is gained. The cost is that the markup now has two sources of truth for the same values, and the next author who wants a different politeness will change one and not the other, producing a contradiction the original author never intended. The narrow argument for writing the explicit values is compatibility with older implementations that did not apply role defaults reliably; that argument has weakened as browsers converged on the mappings, and it is not a reason to write both everywhere.

The rule that follows: choose the role that has the behaviour required, and write explicit attributes only to express a deliberate deviation, with a comment saying why. Writing both the role and its own defaults is a second source of truth for a fact that has one.

alert, status, and what differs beyond politeness

The politeness difference is the visible one, and there are two others.

alert is for content that appears in response to something the user did not do, or to a consequence they cannot see. A failed save, a dropped connection, an error injected by validation after a submit. status is for progress and confirmation of the user’s own action: a save that succeeded, a filter that returned a count, a step that completed. The distinction is about whether the message invalidates the current context, and it maps onto whether interrupting is justified.

alertdialog is not a live region in the ordinary sense. It is a dialog role with assertive politeness and aria-modal="true", and it is meant for the case where a message requires a decision before the user can continue, such as an expiring session with a renew button. The mechanics of making it modal are the same as for any dialog, covered in modal inertness and focus containment, and using alertdialog without the modal behaviour gives an element announced as a modal dialog that does not contain focus.

The other difference is what the roles do to the tree beyond liveness. status and alert are both containers rather than items, and neither is a substitute for a heading or a label. An alert’s content is its own text, and a status element with an aria-label will have that label announced alongside the content in some readers, which is usually unwanted noise.

The empty-container requirement, restated for roles

The ordering requirement from how live regions turn DOM mutations into speech applies identically to these roles, and the roles make the failure more likely because they look like content elements.

<!-- present at load, empty: mutations are announced -->
<p role="status" id="save-state"></p>

<!-- present at load, already populated: usually announced once at load, if at all -->
<p role="status" id="page-state">12 results</p>

An element with role="status" and content already inside it is a region whose initial content was never a mutation. Some readers announce it when the page loads, some do not, and the ones that do may announce it again when the page’s dynamic updates replace it. An empty container that is filled later has one behaviour: the fill is a mutation and it is announced.

The alert role has an additional wrinkle worth knowing. Because the role is assertive, an alert that exists in the document from load carries content that a reader may speak as soon as it discovers the element, before the user has context. The convention that avoids this is the same empty container, filled on the event that warrants the alert. An alert that is created and filled in one operation has the creation problem described earlier and typically announces nothing, which is a quieter failure but still a failure.

When the role is the wrong tool

The live roles are convenient because they are one attribute, and that convenience hides the two decisions the author should be making: politeness and atomicity. A countdown, a stock ticker, a progress percentage updated on every frame, none of these should be announced, and role="timer" or role="marquee" with their implicit off values is the honest way to say so, provided the author then does not “fix” the silence by adding aria-live="polite".

The case where a role is genuinely wrong is the message that must be announced but is not a status or an alert. A toast confirming that a copy succeeded is a status; a toast reporting that the clipboard write was blocked by the browser is an alert. A message that repeats information already in the tree, such as the validation text that is also the field’s aria-describedby target, should not be a live region at all, because the description is read when the field is visited and a region announcing it again doubles the message. Assigning each change to one channel is the same rule as before, and the role vocabulary does not enforce it.

The remaining advanced problem is the one that defeats all of this: a region whose content is rebuilt by a rendering layer rather than edited in place. The mutations a live region depends on may never occur, because the framework replaces the node instead of changing its text. That case is treated in live regions under re-rendering.