There are two solutions to ARIA Live Region issues:

1. Don’t use ARIA Live Regions (but use focus, dialogs, or other managing of what’s going on)
2. Put the live region in the DOM at page load (They cost nothing. If you need an alert and a status, put two divs in with both roles.)

See more in these slides:

https://talks.yatil.net/Ux0REi/were-aria-live

#a11y #accessibility

We’re ARIA Live! by Eric Eggert

Find (accessible) HTML slides here: https://slides.yatil.net/were-aria-live.html

I should update and record this talk and send it to my supporters on Steady.
@yatil The <output> HTML element is often forgotten.
@ctomczyk @yatil i came here to say this

@mikemai2awesome @ctomczyk I like <output>, and I cannot lie. But nobody can deny, that other devs like to use <divs> and over-engineer them until it fits.

(But yes, good point, I should mention that it’s equivalent to using the status role and can be labelled which is quite unique. https://www.w3.org/TR/html-aam-1.0/#el-output)

HTML Accessibility API Mappings 1.0

HTML Accessibility API Mappings (HTML-AAM) defines how user agents map HTML [HTML] elements and attributes to platform accessibility application programming interfaces (APIs). It leverages and extends the Core Accessibility API Mappings 1.2 and the Accessible Name and Description Computation 1.2 for use with the HTML host language. Documenting these mappings promotes interoperable exposure of roles, states, properties, and events implemented by accessibility APIs and helps to ensure that this information appears in a manner consistent with author intent.

@yatil @ctomczyk i like using output for things that are already visible on the page on load, like the number in a stepper UI, or the "x of y" position of a carousel.