E-mail List Archives
Thread: AJAX accessibility issue
Number of posts in this thread: 15 (In chronological order)
From: Ritz, Courtney L. (GSFC-7500)
Date: Thu, Mar 22 2012 8:45AM
Subject: AJAX accessibility issue
No previous message | Next message →
Hi all,
Apologies if this topic has already been discussed on-list. Because it's a rather last-minute issue, I haven't had time to dig through the archives.
We have a Web application here that uses some AJAX in at least one Web form. I can't link to the Web app because it's password-protected and behind our firewall, sorry. In this form, the user selects an item, which causes some new form fields to appear for that selected item. As a JAWS user, when I select one of these items, I get no feedback whatsoever that anything has occurred at all.
The developer is currently trying some of the suggestions demonstrated on the Juicy Studios site. While they work, they require me to turn off the JAWS virtual PC cursor in order to hear the notification that the action has taken place. To me, while this is technically doable, it requires extra steps that the average JAWS user here isn't going to wish to bother with. Not only that, I don't know how or if this works with other screen readers.
Are there any better solutions to this that I can suggest to the developer, or is the best solution to find a non-AJAX method for performing these functions? Whatever we go with has to be able to be considered Section 508 compliant, obviously.
Thanks much.
Courtney
From: Humbert, Joseph A
Date: Thu, Mar 22 2012 9:03AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
Hi Courtney,
An ARIA alert could possibly be used. It is supported by most major screen reading software, but I am not sure how each software treats an ARIA alert, so a non-AJAX solution may be best.
Aria Alert : http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alert
More info: http://www.w3.org/TR/wai-aria-practices/#docmgt
The entire WAI-ARIA Authoring Practices document is a good read. Hope this helps.
Joe Humbert, Assistive Technology and Web Accessibility Specialist
UITS Adaptive Technology and Accessibility Centers
Indiana University, Indianapolis and Bloomington
535 W Michigan St. IT214 E
Indianapolis, IN 46202
Office Phone: (317) 274-4378
Cell Phone: (317) 644-6824
= EMAIL ADDRESS REMOVED =
http://iuadapts.Indiana.edu/
From: John Martyn DoItBlind.com
Date: Thu, Mar 22 2012 9:21AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
Can you try a forced screen refresh with JAWS key + escape and see if that
does anything. I have encountered some pages like this and the screen
refresh worked in some cases.
John Martyn
From: Ryan Hemphill
Date: Thu, Mar 22 2012 9:27AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
You might also want to try this thing as an isolated case first to get the
bugs out - this is one of those situations where a model would serve your
interests by insuring that you are working it out on the isolated prototype
before you trying adding it into the rest of the page.
Incidentally, is this form content being generated by XML/XSLT? Just
curious.
Ryan
On Thu, Mar 22, 2012 at 11:20 AM, Ryan Hemphill <
= EMAIL ADDRESS REMOVED = > wrote:
> I know that some people are going to think this is a terrible way to deal
> with the problem - but I think it will work.
>
> Push the JAWS screen reader into forms mode. It is only a step away from
> application mode and "Virtual Cursor Off" and you may get the results that
> you are looking for.
>
> One way to do this is to drop the focus (after clicking the button) onto a
> text field. Considering that you are adding form data, this might be a
> viable alternative. I strongly suspect that you will get the behaviors you
> described.
>
> If not, oh well - it was worth a shot, right?
>
>
> Ryan
>
>
>
>
> On Thu, Mar 22, 2012 at 11:03 AM, Humbert, Joseph A < = EMAIL ADDRESS REMOVED = >wrote:
>
>> Hi Courtney,
>>
>> An ARIA alert could possibly be used. It is supported by most major
>> screen reading software, but I am not sure how each software treats an ARIA
>> alert, so a non-AJAX solution may be best.
>>
>> Aria Alert : http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alert<http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alert>;
>>
>> More info: http://www.w3.org/TR/wai-aria-practices/#docmgt<http://www.w3.org/TR/wai-aria-practices/#docmgt>;
>>
>> The entire WAI-ARIA Authoring Practices document is a good read. Hope
>> this helps.
>>
>> Joe Humbert, Assistive Technology and Web Accessibility Specialist
>> UITS Adaptive Technology and Accessibility Centers
>> Indiana University, Indianapolis and Bloomington
>> 535 W Michigan St. IT214 E
>> Indianapolis, IN 46202
>> Office Phone: (317) 274-4378
>> Cell Phone: (317) 644-6824
>> = EMAIL ADDRESS REMOVED =
>> http://iuadapts.Indiana.edu/
>>
From: Ryan Hemphill
Date: Thu, Mar 22 2012 9:33AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
I could be wrong but dropping it into the forms mode should do the same
thing. Like I said, it could be wrong, but I would give that a shot as
well.
Ryan
On Thu, Mar 22, 2012 at 11:25 AM, John Martyn DoItBlind.com <
= EMAIL ADDRESS REMOVED = > wrote:
> Can you try a forced screen refresh with JAWS key + escape and see if that
> does anything. I have encountered some pages like this and the screen
> refresh worked in some cases.
> John Martyn
>
>
From: Ryan Hemphill
Date: Thu, Mar 22 2012 9:39AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
I know that some people are going to think this is a terrible way to deal
with the problem - but I think it will work.
Push the JAWS screen reader into forms mode. It is only a step away from
application mode and "Virtual Cursor Off" and you may get the results that
you are looking for.
One way to do this is to drop the focus (after clicking the button) onto a
text field. Considering that you are adding form data, this might be a
viable alternative. I strongly suspect that you will get the behaviors you
described.
If not, oh well - it was worth a shot, right?
Ryan
On Thu, Mar 22, 2012 at 11:03 AM, Humbert, Joseph A < = EMAIL ADDRESS REMOVED = >wrote:
> Hi Courtney,
>
> An ARIA alert could possibly be used. It is supported by most major screen
> reading software, but I am not sure how each software treats an ARIA alert,
> so a non-AJAX solution may be best.
>
> Aria Alert : http://www.w3.org/TR/2010/WD-wai-aria-20100916/roles#alert
>
> More info: http://www.w3.org/TR/wai-aria-practices/#docmgt
>
> The entire WAI-ARIA Authoring Practices document is a good read. Hope
> this helps.
>
> Joe Humbert, Assistive Technology and Web Accessibility Specialist
> UITS Adaptive Technology and Accessibility Centers
> Indiana University, Indianapolis and Bloomington
> 535 W Michigan St. IT214 E
> Indianapolis, IN 46202
> Office Phone: (317) 274-4378
> Cell Phone: (317) 644-6824
> = EMAIL ADDRESS REMOVED =
> http://iuadapts.Indiana.edu/
>
From: Ritz, Courtney L. (GSFC-7500)
Date: Thu, Mar 22 2012 10:45AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
Hi,
I spoke to the developer, she doesn't think there's any XML or XSLT involved.
I'm going to send along your suggestions to her as she's not currently on the WEBAIM list.
Thanks!
courtney
From: Ritz, Courtney L. (GSFC-7500)
Date: Thu, Mar 22 2012 10:51AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
Hi,
I'll have to try that.
Courtney
From: Tony Olivero
Date: Thu, Mar 22 2012 10:57AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
When you say you get no feedback, do you mean there is no annunciation
by JAWS, or the buffer does not update to show the new controls?
Can you find controls by manually tabbing or arrowing?
There are potentially different solutions to either scenario.
Tony
On 3/22/12, Ritz, Courtney L. (GSFC-7500) < = EMAIL ADDRESS REMOVED = > wrote:
> Hi all,
>
> Apologies if this topic has already been discussed on-list. Because it's a
> rather last-minute issue, I haven't had time to dig through the archives.
>
> We have a Web application here that uses some AJAX in at least one Web form.
> I can't link to the Web app because it's password-protected and behind our
> firewall, sorry. In this form, the user selects an item, which causes some
> new form fields to appear for that selected item. As a JAWS user, when I
> select one of these items, I get no feedback whatsoever that anything has
> occurred at all.
>
> The developer is currently trying some of the suggestions demonstrated on
> the Juicy Studios site. While they work, they require me to turn off the
> JAWS virtual PC cursor in order to hear the notification that the action has
> taken place. To me, while this is technically doable, it requires extra
> steps that the average JAWS user here isn't going to wish to bother with.
> Not only that, I don't know how or if this works with other screen readers.
>
> Are there any better solutions to this that I can suggest to the developer,
> or is the best solution to find a non-AJAX method for performing these
> functions? Whatever we go with has to be able to be considered Section 508
> compliant, obviously.
>
> Thanks much.
>
> Courtney
>
From: Ritz, Courtney L. (GSFC-7500)
Date: Thu, Mar 22 2012 11:03AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
Hi Tony,
The new controls are shown, but JAWS does not announce that anything has changed.
Courtney
From: Jared Smith
Date: Thu, Mar 22 2012 11:27AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
On Thu, Mar 22, 2012 at 10:59 AM, Ritz, Courtney L. wrote:
> Hi Tony,
>
> The new controls are shown, but JAWS does not announce that anything has changed.
Does it need to? JAWS users don't always have to be informed of
content or interface updates that occur in other areas of the page,
especially if those content updates are easily found simply by
navigating or reading forward. It sounds in this case that you may be
trying to find a solution to a problem that doesn't exist. In other
words, the user may not care that an update has occurred, so long as
the updated content is accessible when they get to it.
Jared
From: Steve Faulkner
Date: Thu, Mar 22 2012 11:33AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
Hi courtney,
sounds like a job for ARIA live regions;
explained here: http://www.w3.org/WAI/PF/aria-practices/#docmgt
and this demo video may be helpful:
ARIA Live Regions Screen Reader Demo:
http://www.youtube.com/watch?v=9nZnTdSAkH0
regards
Stevef
On 22 March 2012 16:59, Ritz, Courtney L. (GSFC-7500) <
= EMAIL ADDRESS REMOVED = > wrote:
> Hi Tony,
>
> The new controls are shown, but JAWS does not announce that anything has
> changed.
>
> Courtney
>
>
From: Ryan Hemphill
Date: Thu, Mar 22 2012 11:39AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
Good. There can be a loss of synch that can happen between JAWS and IE
when the XML/XSLT is being used because JAWS uses both MSAA and screen
scraping to handle its DOM content. The MSAA sends it at a different time
and they can end up going boom! in some cases.
Have fun,
Ryan
On Thu, Mar 22, 2012 at 12:48 PM, Ritz, Courtney L. (GSFC-7500) <
= EMAIL ADDRESS REMOVED = > wrote:
> Hi,
>
> I spoke to the developer, she doesn't think there's any XML or XSLT
> involved.
>
> I'm going to send along your suggestions to her as she's not currently on
> the WEBAIM list.
>
> Thanks!
>
> courtney
>
>
From: Tony Olivero
Date: Thu, Mar 22 2012 11:45AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →
Courtney,
My question then is more related to focus and user behavior. If the
new controls appear after a blur, you may have to do some JS focus
redirection, certainly if they are appearing outside of the
immediately contiguous tab order this is the case. If however, they
are appearing in the tab order immediately following the control, and
fast enough to be included when the user presses TAB, an alert may not
be necessary.
I'd have to have a better idea of the user behavior to answer it
better, but focus redirection may be a bigger help than an alert.
Tony
On 3/22/12, Ritz, Courtney L. (GSFC-7500) < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Tony,
>
> The new controls are shown, but JAWS does not announce that anything has
> changed.
>
> Courtney
>
>
From: Ritz, Courtney L. (GSFC-7500)
Date: Thu, Mar 22 2012 12:03PM
Subject: Re: AJAX accessibility issue
← Previous message | No next message
Hi,
Hmmm.
I agree with you on the content that shows up further down the page.
I guess, for me, it's a question of how much further down the page. In this case, the new content starts with the very next form field.
Admittedly, this is my first experience with AJAX and JAWS behaviors, at least here at work. I'm not used to not receiving notification that hitting Enter on a control has performed any action. So I may be using too much of my personal preference to determine what's right or wrong, instead of what officialy constitutes accessibility or inaccessibility. (grins)
That's why I love learning so much from this list.
Courtney