E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 9 (In chronological order)

From: Schafer, Carmen
Date: Mon, Jul 02 2018 11:08AM
Subject: alert issue
No previous message | Next message →

Hello, we have an online form with radio buttons and combo boxes. As you fill out the form any changes automatically update the cost of attendance which is located in a table below the form. I tested this form using Firefox 60 and NVDA 2018.2.1 and JAWS 2018. I found the following accessibility issues:

* The radio button labels (In-state & Out-of State) are correctly read by NVDA and JAWS until you select the 'Out-of State' radio button. The total is updated in the table below the form and the cost of attendance amount alert is announced to the SR user, but NVDA no longer reads either radio button label and only the alert is announced using the Arrow keys to navigate the radio buttons. The screen reader user must Tab (key) to the next form control and Tab (key) back to the radios buttons for the labels to be read again by NVDA.



* On the combo boxes, the alert is read before the drop down list items. I'm not sure whether this is an issue since the screen reader does read the list items after the alert message.

Code snippets:
Form
<p>
Please fill out the form below to estimate your cost of attendance.
</p>

<form action="#" style="margin-bottom: 1em;">
<fieldset>
<legend>Select your residency</legend>
<label for="in-state">In-State</label>
<input type="radio" name="residency" id="in-state" value="resident" checked="checked" />

<label for="out-of-state">Out-of State</label>
<input type="radio" name="residency" id="out-of-state" value="non-resident" />
</fieldset>

<fieldset>
<legend>Student level</legend>
<label for="level">Select your student level</label>
<select id="level" name="level">
<option value="undergraduate" selected="selected">Undergraduate</option>
<option value="graduate">Graduate</option>
<option value="law-jd">Law, JD</option>
<option value="law-llm">Law, LLM</option>
<option value="medicine-md">Medicine, MD</option>
<option value="vet-med-dvm">Veterinary Medicine, DVM</option>
</select>
</fieldset>

Table with Alert
<td role="alert">
<a href="#" id="marker-cost-total-anchor" style="text-decoration: none;">
<span class="sr-only">Your estimated cost of attendance is:</span>
<span id="marker-cost-total"></span>
</a>
</td>

Here's a synopsis of how the developer approached the solution:
I was using aria-live polite/assertive on a region to announce changes to the cost of attendance, however I wasn't happy with how quickly the screen reader was announcing changes. It seemed to always read them last, and depending on how the user was interacting with the form, this could cause a significant delay between when the form was changed, and when the result of that change were announced. I replaced the aria-live method with a role of alert, and this caused the change to be announced immediately but has the added side effect of not announcing further information about the form. The only mechanism present on the page now is role="alert."


Does anyone have any suggestions on how to fix the radio button label issue and improve the notification of changes to a screen reader user? Also, let me know if I did not provide enough information.


Thanks for any guidance.

Carmen Schafer
University of Missouri

From: glen walker
Date: Mon, Jul 02 2018 12:18PM
Subject: Re: alert issue
← Previous message | Next message →

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

From: Schafer, Carmen
Date: Mon, Jul 02 2018 1:06PM
Subject: Re: alert issue
← Previous message | Next message →

Glen, thank you for providing this helpful information.

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: Monday, July 2, 2018 1:18 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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

From: Birkir R. Gunnarsson
Date: Mon, Jul 02 2018 1:09PM
Subject: Re: alert issue
← Previous message | Next message →

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 ADDRESS 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.

From: Tim Harshbarger
Date: Tue, Jul 03 2018 6:56AM
Subject: Re: [EXTERNAL] alert issue
← Previous message | Next message →

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 ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Monday, July 2, 2018 2:10 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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.

From: Schafer, Carmen
Date: Tue, Jul 03 2018 12:12PM
Subject: Re: [EXTERNAL] alert issue
← Previous message | Next message →

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 ADDRESS REMOVED = > On Behalf Of Tim Harshbarger
Sent: Tuesday, July 3, 2018 7:56 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Monday, July 2, 2018 2:10 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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.

From: Isabel Holdsworth
Date: Fri, Jul 13 2018 9:45AM
Subject: Re: [EXTERNAL]alert issue
← Previous message | Next message →

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 ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Tim
> Harshbarger
> Sent: Tuesday, July 3, 2018 7:56 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = ] On Behalf
> Of Birkir R. Gunnarsson
> Sent: Monday, July 2, 2018 2:10 PM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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
> >
>
> > > > > > > > >

From: glen walker
Date: Fri, Jul 13 2018 1:21PM
Subject: Re: [EXTERNAL]alert issue
← Previous message | Next message →

Anyone know if RTL users/languages prefer the radiobuttons and checkboxes
to the right of the label? Would magnifier users stick to the right margin?

On Fri, Jul 13, 2018 at 9:45 AM, Isabel Holdsworth <
= EMAIL ADDRESS REMOVED = > wrote:

>
> 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
>

From: JP Jamous
Date: Fri, Jul 13 2018 1:31PM
Subject: Re: [EXTERNAL]alert issue
← Previous message | No next message

Glen,

Since I speak Arabic, I would say yes to your questions. When I used to have
sight and used to read books, my eye would be always aiming at that right
margin.

This same concept applies to RTL on computer screens. When the user looks at
the screen, he or she would be looking at the right side of the page
regardless of whether the rest of the browser buttons or menus are in
English, French or other LTR languages.



--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen
walker
Sent: Friday, July 13, 2018 2:21 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Re: alert issue

Anyone know if RTL users/languages prefer the radiobuttons and checkboxes to
the right of the label? Would magnifier users stick to the right margin?

On Fri, Jul 13, 2018 at 9:45 AM, Isabel Holdsworth <
= EMAIL ADDRESS REMOVED = > wrote:

>
> 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
>
http://webaim.org/discussion/archives