WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: AJAX accessibility issue

for

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/
-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ritz, Courtney L. (GSFC-7500)
Sent: Thursday, March 22, 2012 10:48 AM
To: WebAIM Discussion List ( = EMAIL ADDRESS REMOVED = )
Subject: [WebAIM] AJAX accessibility issue

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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ritz, Courtney L.
(GSFC-7500)
Sent: Thursday, March 22, 2012 7:48 AM
To: WebAIM Discussion List ( = EMAIL ADDRESS REMOVED = )
Subject: [WebAIM] AJAX accessibility issue

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: 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/
>> -----Original Message-----
>> From: webaim-forum-bounces@list.​webaim.org< = EMAIL ADDRESS REMOVED = >[mailto:
>> webaim-forum-bounces@​list.webaim.org< = EMAIL ADDRESS REMOVED = >]
>> On Behalf Of Ritz, Courtney L. (GSFC-7500)
>> Sent: Thursday, March 22, 2012 10:48 AM
>> To: WebAIM Discussion List ( = EMAIL ADDRESS REMOVED = )
>> Subject: [WebAIM] AJAX accessibility issue
>>
>> 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: 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
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ritz, Courtney
> L.
> (GSFC-7500)
> Sent: Thursday, March 22, 2012 7:48 AM
> To: WebAIM Discussion List ( = EMAIL ADDRESS REMOVED = )
> Subject: [WebAIM] AJAX accessibility issue
>
> 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: 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/
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Ritz, Courtney L.
> (GSFC-7500)
> Sent: Thursday, March 22, 2012 10:48 AM
> To: WebAIM Discussion List ( = EMAIL ADDRESS REMOVED = )
> Subject: [WebAIM] AJAX accessibility issue
>
> 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 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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ryan Hemphill
Sent: Thursday, March 22, 2012 11:23 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] AJAX accessibility issue

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-2
>> 0100916/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/
>> -----Original Message-----
>> From: webaim-forum-bounces@list.​webaim.org< = EMAIL ADDRESS REMOVED = >[mailto:
>> webaim-forum-bounces@​
>> list.webaim.org< = EMAIL ADDRESS REMOVED = >]
>> On Behalf Of Ritz, Courtney L. (GSFC-7500)
>> Sent: Thursday, March 22, 2012 10:48 AM
>> To: WebAIM Discussion List ( = EMAIL ADDRESS REMOVED = )
>> Subject: [WebAIM] AJAX accessibility issue
>>
>> 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 10:51AM
Subject: Re: AJAX accessibility issue
← Previous message | Next message →

Hi,

I'll have to try that.

Courtney

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of John Martyn DoItBlind.com
Sent: Thursday, March 22, 2012 11:25 AM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] AJAX accessibility issue

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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Ritz, Courtney L.
(GSFC-7500)
Sent: Thursday, March 22, 2012 7:48 AM
To: WebAIM Discussion List ( = EMAIL ADDRESS REMOVED = )
Subject: [WebAIM] AJAX accessibility issue

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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tony Olivero
Sent: Thursday, March 22, 2012 12:51 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] AJAX accessibility issue

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: 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
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Tony Olivero
> Sent: Thursday, March 22, 2012 12:51 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] AJAX accessibility issue
>
> 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: 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
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Ryan Hemphill
> Sent: Thursday, March 22, 2012 11:23 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] AJAX accessibility issue
>
> 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-2
> >> 0100916/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/
> >> -----Original Message-----
> >> From: webaim-forum-bounces@list.​webaim.org<
> = EMAIL ADDRESS REMOVED = >[mailto:
> >> webaim-forum-bounces@
> >> list.webaim.org< = EMAIL ADDRESS REMOVED = >]
> >> On Behalf Of Ritz, Courtney L. (GSFC-7500)
> >> Sent: Thursday, March 22, 2012 10:48 AM
> >> To: WebAIM Discussion List ( = EMAIL ADDRESS REMOVED = )
> >> Subject: [WebAIM] AJAX accessibility issue
> >>
> >> 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: 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
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tony Olivero
> Sent: Thursday, March 22, 2012 12:51 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] AJAX accessibility issue
>
> 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 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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jared Smith
Sent: Thursday, March 22, 2012 1:18 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] AJAX accessibility issue

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