By OZeWAI member Andrew Downie, Accessibility Consultant.
This item was inspired by Florian Schroiff’s article, How to Use ARIA Alert Effectively. Florian makes some good points about ensuring screen reader users do not miss out on important information. His examples are also very effective.
I do have one issue though. My experience is that role="assertive"
is much overused. He strongly advocates use of that role, while perhaps my favourite, aria-live="polite"
barely gets a mention.
Polite, assertive and alert
While it can get more complicated, the following three ARIA roles can be used to present information to screen reader users without having to put focus on the relevant element:
aria-live="polite"
aria-live="assertive"
role="alert"
“Polite” waits for the screen reader to finish what it is presenting before chiming in with the new material while “Assertive” jumps in immediately. So what about “Alert”? It behaves just like “Assertive” except that it adds “Alert” before presenting the information.
That might be considered helpful if the user has, say, missed a required field in a form or even more so if a session is about to time out. But using it as the go-to role for presenting relevant information to screen reader users is, in my view, both unnecessary and irritating. Florian states that:
“It’s equivalent to setting both
aria-live="assertive"
andaria-atomic="true"
on an element.”
Except that aria-live="assertive"
does not precede the relevant information with “Alert”. While that one word seems like not much of an imposition, when it happens dozens of times during a day it (a) loses its significance and (b) irritates grumpy people like me.
Killing with kindness
Many web authors, either through blissful ignorance or indifference, create sites that fall well short of access for a broad range of visitors. When striving to create fully accessible sites, there is the risk of being “too nice”. As a screen reader user, it is most disarming to, say, press a button and receive no feedback. So, while immediate feedback is important, it does not need to be preceded by “Alert”. aria-live="polite"
or, if in doubt, aria=live="assertive"
will almost always do the job effectively.
Early in the piece, I mentioned that these ARIA roles present information to screen readers without putting focus on the relevant element. There are times when it is important to shift focus to the element rather than using ARIA. Modal dialogs are crucial examples, but there are plenty of others.
While on dialogs, Florian mentions role="alertdialog"
.
There’s also
role="alertdialog"
, which is similar but different. While both roles announce content, “alertdialog” moves the user’s focus to the alert and expects them to close it – perfect for those “Your session is about to expire” warnings.
Not quite correct. Putting role="alertdialog"
on an element does not move focus to it. That must be done with scripting; I am sure he knows that and assumed readers would.
Summary
In the vast majority of cases, when something on the page changes that screen reader users need to know about and where focus change is not necessary, “polite” or perhaps “assertive” are completely adequate. Too many web pages and software (looking at you, Zoom) overuse “alert”.
Florian suggests including aria-atomic="true"
(the default state is “false”). It only becomes relevant in cases where the target node is a child of one where the aria-live
role is set and you want both existing and new information to be presented. Read this page if I just lost you.