WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: [EXTERNAL]alert issue

for

From: Isabel Holdsworth
Date: Jul 13, 2018 9:45AM


Hi Carmen,

Just a few thoughts:

If the amount is updated using JavaScript, I probably wouldn't use
aria-describedby to link the form elements with the amount. If a
screenreader is browsing the form element without activating it, the
amount may be incorrect if the JavaScript update event hasn't been
triggered.

Also, a bit pedantic this, but it's good protocol to position
radiobuttons and checkboxes to the left of their labels. Some screen
magnifier users, especially if the text size is increased
dramatically, stick near the left margin so they can scroll straight
down the page, and they might miss your radiobuttons.

Cheers - have a great weekend.

Lynn

On 03/07/2018, Schafer, Carmen < <EMAIL REMOVED> > wrote:
> Thanks for your input, Tim, and everyone who responded. I like to learn
> from all the perspectives in order to come to the best solution for as many
> people as possible.
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Tim
> Harshbarger
> Sent: Tuesday, July 3, 2018 7:56 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] [EXTERNAL] Re: alert issue
>
> 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
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > http://webaim.org/discussion/archives
> >
>
> > > > > > > > >