WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: alert issue

for

From: Schafer, Carmen
Date: Jul 2, 2018 1:06PM

Glen, thank you for providing this helpful information.

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of glen walker
Sent: Monday, July 2, 2018 1:18 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] alert issue

Hi Carmen,

One clarification on what your developer said. They said they tried aria-live of polite and assertive and then "replaced the aria-live method with a role of alert, and this caused the change to be announced immediately".

A role="alert" gives you an implicit setting of aria-live="assertive", so your developer hasn't really replaced aria-live. They still have aria-live but it's implied in the role="alert".

They should have heard the changes announced immediately by simply using aria-live="assertive", however, that might not be the proper setting in your case.

Using aria-live="assertive", or more extreme, using role="alert", should be reserved for truly time-sensitive alerts that might cause problems if the user were not notified immediately. When calculating college costs by selecting various options (such as in-state or out-of-state), to me, that doesn't seem like an urgent message and aria-live="polite" should suffice.
Suppose a screen reader user has visited that page several times because they're trying various options over the span of several days. They will be used to the layout of the page by then and could quickly navigate to several options and select them. After each option is (quickly) set, having the total amount updated every time after an option changed by using role="alert" would be audible noise. They'd want to hear the changes after they selected all the options, which is what should happen with aria-live="polite". If options were changed slowly, then you'd still hear each aria-live update individually, but if you change options quickly, hopefully the screen reading software queues all the changes and coalesces them into one announcement.

You start getting into dangerous waters if a non-screen reader user attempts to guess at what a regular screen reader user might want.

Now, all this is sort of beside the point of your original question, that radio buttons and aria-live changes seem to be lost. I do know that with aria-live="assertive" (whether that's set directly or implicitly by using role="alert"), that screen reading software has the option to clear all other pending live announcements. "User agents or assistive technologies MAY choose to clear queued changes when an assertive change occurs". See https://www.w3.org/TR/wai-aria-1.1/#aria-live. So that *might* be causing the behavior you're seeing.

If you had test versions of the various aria-live options, that would help us figure out the problem.

Glen