WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: alert issue

for

From: Birkir R. Gunnarsson
Date: Jul 2, 2018 1:09PM


I've been working on a live filtering component that is screen reader friendly.
We've settled on the following:
1. Include a visually hidden sentence after the legend but before the
radio buttons that say "activating these controls will change the
amount in the table" (well, ours is worded differently but it would be
in your case). This way you set the expectation once without making
too much noise.
2. Add aria-live="polite" I would set it on the <a> element instead of
the <td> The span inside the <a> is updated independently so there's
less text to announce.
3. (optional) use either aria-describedby or aria-controls to point
from the radio buttons and dropdownto the <span> with the amount
(assuming that span has a unique id).
Both cause additional screen reader verbosity. aria-controls is either
not announced or the keyboard shortcut to it Is announced for every
radio button (Jaws). Semantially this is the right thing to do, but
screen readers have not turned this code into the ideal user
experience yet.
aria-describedby would cause the amount to be announced every time the
user navigates to a radio button or to the dropdown, again it could be
too verbose. You'd need some testing to figure out if one or both of
thes would be helpful or the most helpful thing would be to not do
either.




On 7/2/18, glen walker < <EMAIL REMOVED> > wrote:
> 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
> > > > >


--
Work hard. Have fun. Make history.