WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: [EXTERNAL] alert issue

for

From: Tim Harshbarger
Date: Jul 3, 2018 6:56AM

Another option might be to remove the live region. Instead make the cost information available as part of the label for the choice. This probably would work better for people using magnification. Also, it might be more useful for all users when they do have a choice of which option to pick. I have seen a similar approach used some times on sites where you select a computer to purchase and then are provided with options to modify the base package.

To me, I am not sure if the issue the developer originally noticed when using aria-live="polite|assertive" was something that needed to be fixed. I am not sure how to explain this, but I will give it a try. When testing with a screen reader, there are a lot of issues you can uncover. Some of those issues are quite obvious--like a missing alt attribute on an img (image) element. Others have more to do with the perception of the tester. It can be tougher to determine which of those issues is an accessibility issue, might be an accessibility issue, or just is the nature of a non-visual interface. My own opinion is that any time information is not conveyed by the screen reader, it is definitely an accessibility issue. However, this seems to involve a delay of information being conveyed. If this live region isn't acting any different from any other live region with polite or assertive on it, I wouldn't consider it an issue--unless I had definite user testing to demonstrate that. Ho
wever, I would definitely consider it an accessibility issue in the situation where the role="alert" causes NVDA not to provide the label information at all.

As a side note--I am blind myself and use a screen reader. I don't even consider most of the testing I do with a screen reader to be equivalent to user testing--since most of the time I am supposed to be hyper-focused on finding all the accessibility issues with a page rather than just focusing on performing a task like most users do.

This isn't a criticism on the great advice you have already received, but is just intended as another perspective to the problem.

Thanks!
Tim
-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R. Gunnarsson
Sent: Monday, July 2, 2018 2:10 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: [EXTERNAL] Re: [WebAIM] alert issue

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.