You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Alerts are assertive live regions, which means they cause immediate notification for assistive technology users. If the operating system allows, the user agent SHOULD fire a system alert event through the accessibility API when the WAI-ARIA alert is created.
The "when the WAI-ARIA alert is created" part is handwavy and vague.
Currently (even though this is not really specified well either - more on this in a separate issue I'll be filing) with live regions, the most reliable way to trigger a live region correctly is to make sure that the live region element/container is "seen" by the browser first, giving AT a chance to then register for the events that are fired when the region's content changes. only then, you'd want to populate the live region element (by dynamically injecting content, or by flipping the visibility of a node inside it, or similar). So, based on the first sentence ("Alerts are assertive live regions"), you'd assume that role="alert" elements have the same behaviour.
However, it appears that in most browser/screen reader combinations, role="alert" is treated slightly magically/special: it seems to trigger an actual SR announcement even if the node is created already fully populated with content. Usually, it even fires an alert notification when the fully populated role="alert" element is present in the markup of the page on first page load.
This specification does not currently contain guidance for when user agents should fire system alert events. Some guidance may be added to the specification at a later date but it will be a recommendation (SHOULD), not a requirement (MUST).
I would strongly urge for "some guidance" to be added both in the ARIA spec, and a matching note in the Core-AAM spec.
The text was updated successfully, but these errors were encountered:
(cross-posted from w3c/aria#2153 as I believe the issue will need considerations in both specs)
Describe your concern
Currently, in the description for
role="alert"
https://www.w3.org/TR/wai-aria-1.3/#alert the ARIA spec statesThe "when the WAI-ARIA alert is created" part is handwavy and vague.
Currently (even though this is not really specified well either - more on this in a separate issue I'll be filing) with live regions, the most reliable way to trigger a live region correctly is to make sure that the live region element/container is "seen" by the browser first, giving AT a chance to then register for the events that are fired when the region's content changes. only then, you'd want to populate the live region element (by dynamically injecting content, or by flipping the visibility of a node inside it, or similar). So, based on the first sentence ("Alerts are assertive live regions"), you'd assume that
role="alert"
elements have the same behaviour.However, it appears that in most browser/screen reader combinations,
role="alert"
is treated slightly magically/special: it seems to trigger an actual SR announcement even if the node is created already fully populated with content. Usually, it even fires an alert notification when the fully populatedrole="alert"
element is present in the markup of the page on first page load.The ARIA spec shies away from defining the expected behavior here. Cross-checking Core-AAM https://www.w3.org/TR/core-aam-1.2/#role-map-alert there's a note https://www.w3.org/TR/core-aam-1.2/#ftn.note2 that actually sidesteps the question completely at this point
I would strongly urge for "some guidance" to be added both in the ARIA spec, and a matching note in the Core-AAM spec.
The text was updated successfully, but these errors were encountered: