Dynamic messages should have an aria-live attribute set on their parent


Dynamic messages that are injected into the DOM without page reload should have an aria-live attribute set on their parent. While reviewing PR 6629 on Ellipses I noticed that a fair number of those messages fall into this category. These visual messages let the user know that the system is working, they should patiently wait, and that everything is OK. Since non-visual users are only interacting with the content on the page that has focus, they are never made aware of such messages. We want to expose these messages to non-visual users without having to force their focus to the message and then return it to where it was. This is where the aria-live attribute can be very handy. Typically, aria-live will take a value of "polite" which will announce the text changes in the region as soon as the screen reader is not busy speaking something else. If your message is very urgent, you can set the property to "assertive." This will immediately interrupt the screen reader, clear its queue and speak the text changes.

A few caveats:
aria-live should not be used on regions that contain interactive content like links, buttons or other form inputs. The users focus is not moved and there is no mechanism for moving it to the live region, so the user would have to hunt for region in the DOM.
It should also not be used for very long messages (more than 140 chars?). Again, since focus is not moved, the user can't repeat or seek out the content again if they missed the message the first time. The message should be clear and simple (Loading, Saving, Updating, etc.)
If the region already has lots of content in it, and only a part of it is changing (like a shopping cart for instance), you can fine tune what types of changes get spoken to the the user using aria-live in combination with aria-relevant




Mark Sadecki