E-mail List Archives
Thread: Wai Aria how useful?
Number of posts in this thread: 27 (In chronological order)
From: Nancy Johnson
Date: Wed, Jul 21 2010 12:27PM
Subject: Wai Aria how useful?
No previous message | Next message →
Hi,
How useful is WAI Aria to the average screen reader user who may not
be technically inclined?
Does this also help the mobility impaired user who is not visually impaired?
I have never integrated WAI ARIA into our sites, but as we are
thinking of AJAX and other technologies I'm wondering if this is a
good option?
Thanks in advance,
Nancy Johnson
From: deblist
Date: Wed, Jul 21 2010 1:15PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
Nancy Johnson wrote:
> How useful is WAI Aria to the average screen reader user who may not be technically inclined?
It depends on what version of a screenreader and browser they
have. With JAWS 11 + Firefox 3, for example, live regions get
announced in ways that some people find helpful (depending on how
well they have encoded).
> Does this also help the mobility impaired user who is not visually impaired?
I have found that there are circumstances in which ARIA
navigation changes the way the wonderful Firefox add-on
Mouseless Browsing interacts with a webpage in a way that gives
me more control over Ajax drop-down menus. I haven't narrowed it
down to exactly what features make things better, but I've been
meaning to.
-deborah
From: Seth Kane
Date: Thu, Jul 22 2010 1:03PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
I have had little to no luck with ARIA unless you have the latest and great version of both browsers and screen readers. It isn't ready for the lowest common denominator just yet. Maybe HTML5 will be better.
Seth Kane
From: Birkir Rúnar Gunnarsson
Date: Thu, Jul 22 2010 1:30PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
There are a few inherent problems with Aria.
To use it I believe that you need Firefox 3.5 or newer, IE8. As for
screen readers I think it is Jaws 10 and above, Window Eyes 7 and
above and Hal/Dolphin 11.2 and above (NVDA does a good job of
recognizing Aria).
You definitely cannot expect your users to be so up-to-date given the
price of upgrades and relatively lousy set of improvements at least in
Jaws lately (no bashing intended, Ijust feel that upgrades from Jaws 9
have hardly been worth it).
Another issue is clashes between screen reader key strokes while
navigating a web page and assigned Aria keyboard shortcuts. The
application element is supposed to turn off screen reader key
functionality but this does not always seem to work properly (I will
admit I lack expertees in this area, I am looking at it but this was
discussed at length at the ICCHP conference I just attended).
Thus a screen reader user must pass every keysroke to an Aria page
through the screen reader by using the designed pass through key, and
that is a relatively advanced operation (or rather, having the user
recognize the need to do this is fairly advanced, one has to
understand what type of page is being encounterred and what that means
for navigation).
Even if both of these issues are resoled and you have a user with
compatible SR and browser and the switching off works, there is still
a worrying lack of standards regarding keyboard mapping of aria
elements, which means the user has to continually return to some type
of on page help to see what keystrokes are required for what action
(See GoogleReader as an example).
These help messages do not (perhaps cannot) appear in a virtual
buffer, meaning it is hard to copy them and recall them in a text
document, so you have to kepp clicking on some type of help / overview
on the page that tells you the functionality of each key stroke.
There is a brilliant video demo about this, I will post it if I manage
to dig it up from my conference lecture notes, which I will have time
for over the weekend.
/basically, yopu have to expect not all users can use Aria and even
for those who can, a lot of thought needs to go in to the key mapping
and you must ensure that the user can access a simple keyboard help
overview in a convenient format somehow (perhaps have it downloadable
as a .txt file or plain html page that opens in a new window or tab).
Hope some of these thoughts help, plesae keep us updated and I will
post back once I have sorted out my notes.
Cheers
-B
On 7/22/10, Seth Kane < = EMAIL ADDRESS REMOVED = > wrote:
> I have had little to no luck with ARIA unless you have the latest and great
> version of both browsers and screen readers. It isn't ready for the lowest
> common denominator just yet. Maybe HTML5 will be better.
>
>
> Seth Kane
>
>
>
From: Steven Faulkner
Date: Thu, Jul 22 2010 3:03PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
hi birkir,
you wrote:
"You definitely cannot expect your users to be so up-to-date given the price
of upgrades..."
The webaim screen readers survey differs from your conclusion
"The vast majority of respondents updated their primary screen reader within
the previous year."
http://www.webaim.org/projects/screenreadersurvey2/#demographics
you wrote:
"Another issue is clashes between screen reader key strokes while
navigating a web page and assigned Aria keyboard shortcuts. "
There are no "ARIA keyboard shortcuts" as such:
The set of keyboard shortcuts defined for use in Google Reader has NOTHING
to do with ARIA.
What ARIA promotes is the implementation of keyboard interactions for
widgets that are the same or similar to those of controls in desktop
software applications
"The model for keyboard support for Web 2.0 widgets are graphical user
> interface (GUI) operating systems like Microsoft Windows, Mac OS X; and
> other desktop operating systems like GNOME and GTK. "
http://www.w3.org/WAI/PF/aria-practices/#kbd_generalnav
There is an ongoing effort to specify keyboard keystrokes to be used for web
based controls:
http://dev.aol.com/dhtml_style_guide
These keyboard interaction best practices are being implemented in
javascript UI libraries such as DOJO and JQUERY so that users can rely upon
the same or similar keystrokes being usable on for example a 'button'
regardless of whether its a native HTML button <button> or a button built
from divs and spans with added script to provide the user interaction.
>Another issue is clashes between screen reader key strokes while
>navigating a web page and assigned Aria keyboard shortcuts. The
>application element is supposed to turn off screen reader key
>functionality but this does not always seem to work properly
There is no clash per se, when in document reading mode, most key strokes
are consumed by the AT, this is why most windows based AT have a special
mode for interacting with native controls on web pages, which allows
keystrokes to be passed to the browser rather than consumed by the AT. ARIA
extends this method to the custom controls built using a combination of
HTML/scripting and CSS.
The use of role="application" on an element indicates to AT that support it
they should switch from document to application mode (so users can interact
with controls using the keyboard). It is true that it sometimes does not
work, but i would suggest it is no more or less buggy than many of the other
features in popular commercial screen readers.
you wrote:
"/basically, yopu have to expect not all users can use Aria and even
for those who can, a lot of thought needs to go in to the key mapping
and you must ensure that the user can access a simple keyboard help
overview in a convenient format somehow (perhaps have it downloadable
as a .txt file or plain html page that opens in a new window or tab)."
again what you are talking about has nothing to do with ARIA, in fact it is
the opposite:
The use of ARIA on custom controls provides users with information about the
role/state and properties of the control which typically results in the AT
providing hints about how to interact with the control.
Tests and examples of what AT report when ARIA roles are encountered:
http://www.paciellogroup.com/blog/aria-tests/user-input-widgets.html
note these results are from 18 months ago.
Regards
Stevef
2010/7/22 Birkir Rúnar Gunnarsson < = EMAIL ADDRESS REMOVED = >
> There are a few inherent problems with Aria.
> To use it I believe that you need Firefox 3.5 or newer, IE8. As for
> screen readers I think it is Jaws 10 and above, Window Eyes 7 and
above and Hal/Dolphin 11.2 and above (NVDA does a good job of
> recognizing Aria).
> You definitely cannot expect your users to be so up-to-date given the
> price of upgrades and relatively lousy set of improvements at least in
> Jaws lately (no bashing intended, Ijust feel that upgrades from Jaws 9
> have hardly been worth it).
> Another issue is clashes between screen reader key strokes while
> navigating a web page and assigned Aria keyboard shortcuts. The
> application element is supposed to turn off screen reader key
> functionality but this does not always seem to work properly (I will
> admit I lack expertees in this area, I am looking at it but this was
> discussed at length at the ICCHP conference I just attended).
> Thus a screen reader user must pass every keysroke to an Aria page
> through the screen reader by using the designed pass through key, and
> that is a relatively advanced operation (or rather, having the user
> recognize the need to do this is fairly advanced, one has to
> understand what type of page is being encounterred and what that means
> for navigation).
> Even if both of these issues are resoled and you have a user with
> compatible SR and browser and the switching off works, there is still
> a worrying lack of standards regarding keyboard mapping of aria
> elements, which means the user has to continually return to some type
> of on page help to see what keystrokes are required for what action
> (See GoogleReader as an example).
> These help messages do not (perhaps cannot) appear in a virtual
> buffer, meaning it is hard to copy them and recall them in a text
> document, so you have to kepp clicking on some type of help / overview
> on the page that tells you the functionality of each key stroke.
> There is a brilliant video demo about this, I will post it if I manage
> to dig it up from my conference lecture notes, which I will have time
> for over the weekend.
> /basically, yopu have to expect not all users can use Aria and even
> for those who can, a lot of thought needs to go in to the key mapping
> and you must ensure that the user can access a simple keyboard help
> overview in a convenient format somehow (perhaps have it downloadable
> as a .txt file or plain html page that opens in a new window or tab).
> Hope some of these thoughts help, plesae keep us updated and I will
> post back once I have sorted out my notes.
> Cheers
> -B
>
> On 7/22/10, Seth Kane < = EMAIL ADDRESS REMOVED = > wrote:
> > I have had little to no luck with ARIA unless you have the latest and
> great
> > version of both browsers and screen readers. It isn't ready for the
> lowest
> > common denominator just yet. Maybe HTML5 will be better.
> >
> >
> > Seth Kane
> >
> >
> >
From: Birkir Rúnar Gunnarsson
Date: Thu, Jul 22 2010 4:45PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
Steve
Thanks very much for all the info.
Like I said I am fairly new to all of this and it appears I
misunderstood a few things, but I am all too happy to be corrected and
will start with the pointers in your post for further research.
The screen reader ownership survey surprises me though, it may be
location specific, because I know the situation in a few countries in
Europe and the user SR ownership seems to differ from this survey, so
it is a good thing.
I will post back with questions/comments after I update my knowledge
some. *grin*
Cheers
-B
On 7/22/10, Steven Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> hi birkir,
>
> you wrote:
> "You definitely cannot expect your users to be so up-to-date given the price
> of upgrades..."
>
> The webaim screen readers survey differs from your conclusion
>
> "The vast majority of respondents updated their primary screen reader within
> the previous year."
> http://www.webaim.org/projects/screenreadersurvey2/#demographics
>
>
> you wrote:
> "Another issue is clashes between screen reader key strokes while
> navigating a web page and assigned Aria keyboard shortcuts. "
>
> There are no "ARIA keyboard shortcuts" as such:
> The set of keyboard shortcuts defined for use in Google Reader has NOTHING
> to do with ARIA.
>
> What ARIA promotes is the implementation of keyboard interactions for
> widgets that are the same or similar to those of controls in desktop
> software applications
>
> "The model for keyboard support for Web 2.0 widgets are graphical user
>> interface (GUI) operating systems like Microsoft Windows, Mac OS X; and
>> other desktop operating systems like GNOME and GTK. "
>
> http://www.w3.org/WAI/PF/aria-practices/#kbd_generalnav
>
> There is an ongoing effort to specify keyboard keystrokes to be used for web
> based controls:
> http://dev.aol.com/dhtml_style_guide
>
> These keyboard interaction best practices are being implemented in
> javascript UI libraries such as DOJO and JQUERY so that users can rely upon
> the same or similar keystrokes being usable on for example a 'button'
> regardless of whether its a native HTML button <button> or a button built
> from divs and spans with added script to provide the user interaction.
>
>>Another issue is clashes between screen reader key strokes while
>>navigating a web page and assigned Aria keyboard shortcuts. The
>>application element is supposed to turn off screen reader key
>>functionality but this does not always seem to work properly
>
> There is no clash per se, when in document reading mode, most key strokes
> are consumed by the AT, this is why most windows based AT have a special
> mode for interacting with native controls on web pages, which allows
> keystrokes to be passed to the browser rather than consumed by the AT. ARIA
> extends this method to the custom controls built using a combination of
> HTML/scripting and CSS.
>
> The use of role="application" on an element indicates to AT that support it
> they should switch from document to application mode (so users can interact
> with controls using the keyboard). It is true that it sometimes does not
> work, but i would suggest it is no more or less buggy than many of the other
> features in popular commercial screen readers.
>
> you wrote:
> "/basically, yopu have to expect not all users can use Aria and even
> for those who can, a lot of thought needs to go in to the key mapping
> and you must ensure that the user can access a simple keyboard help
> overview in a convenient format somehow (perhaps have it downloadable
> as a .txt file or plain html page that opens in a new window or tab)."
>
> again what you are talking about has nothing to do with ARIA, in fact it is
> the opposite:
> The use of ARIA on custom controls provides users with information about the
> role/state and properties of the control which typically results in the AT
> providing hints about how to interact with the control.
>
> Tests and examples of what AT report when ARIA roles are encountered:
> http://www.paciellogroup.com/blog/aria-tests/user-input-widgets.html
> note these results are from 18 months ago.
>
> Regards
> Stevef
>
>
>
> 2010/7/22 Birkir Rúnar Gunnarsson < = EMAIL ADDRESS REMOVED = >
>
>> There are a few inherent problems with Aria.
>> To use it I believe that you need Firefox 3.5 or newer, IE8. As for
>> screen readers I think it is Jaws 10 and above, Window Eyes 7 and
>
> above and Hal/Dolphin 11.2 and above (NVDA does a good job of
>> recognizing Aria).
>> You definitely cannot expect your users to be so up-to-date given the
>> price of upgrades and relatively lousy set of improvements at least in
>> Jaws lately (no bashing intended, Ijust feel that upgrades from Jaws 9
>> have hardly been worth it).
>> Another issue is clashes between screen reader key strokes while
>> navigating a web page and assigned Aria keyboard shortcuts. The
>> application element is supposed to turn off screen reader key
>> functionality but this does not always seem to work properly (I will
>> admit I lack expertees in this area, I am looking at it but this was
>> discussed at length at the ICCHP conference I just attended).
>> Thus a screen reader user must pass every keysroke to an Aria page
>> through the screen reader by using the designed pass through key, and
>> that is a relatively advanced operation (or rather, having the user
>> recognize the need to do this is fairly advanced, one has to
>> understand what type of page is being encounterred and what that means
>> for navigation).
>> Even if both of these issues are resoled and you have a user with
>> compatible SR and browser and the switching off works, there is still
>> a worrying lack of standards regarding keyboard mapping of aria
>> elements, which means the user has to continually return to some type
>> of on page help to see what keystrokes are required for what action
>> (See GoogleReader as an example).
>> These help messages do not (perhaps cannot) appear in a virtual
>> buffer, meaning it is hard to copy them and recall them in a text
>> document, so you have to kepp clicking on some type of help / overview
>> on the page that tells you the functionality of each key stroke.
>> There is a brilliant video demo about this, I will post it if I manage
>> to dig it up from my conference lecture notes, which I will have time
>> for over the weekend.
>> /basically, yopu have to expect not all users can use Aria and even
>> for those who can, a lot of thought needs to go in to the key mapping
>> and you must ensure that the user can access a simple keyboard help
>> overview in a convenient format somehow (perhaps have it downloadable
>> as a .txt file or plain html page that opens in a new window or tab).
>> Hope some of these thoughts help, plesae keep us updated and I will
>> post back once I have sorted out my notes.
>> Cheers
>> -B
>>
>> On 7/22/10, Seth Kane < = EMAIL ADDRESS REMOVED = > wrote:
>> > I have had little to no luck with ARIA unless you have the latest and
>> great
>> > version of both browsers and screen readers. It isn't ready for the
>> lowest
>> > common denominator just yet. Maybe HTML5 will be better.
>> >
>> >
>> > Seth Kane
>> >
>> >
>> >
From: Tania
Date: Thu, Jul 22 2010 9:18PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
wonder what is the readership profile and those who responded to web aim
survey ? i know of people in india, africa and south east asia [where i am
from] still using jaws v4, v5 etc.
regards
tania
----- Original Message -----
From: "Steven Faulkner" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, July 23, 2010 5:02 AM
Subject: Re: [WebAIM] Wai Aria how useful?
hi birkir,
you wrote:
"You definitely cannot expect your users to be so up-to-date given the price
of upgrades..."
The webaim screen readers survey differs from your conclusion
"The vast majority of respondents updated their primary screen reader within
the previous year."
http://www.webaim.org/projects/screenreadersurvey2/#demographics
you wrote:
"Another issue is clashes between screen reader key strokes while
navigating a web page and assigned Aria keyboard shortcuts. "
There are no "ARIA keyboard shortcuts" as such:
The set of keyboard shortcuts defined for use in Google Reader has NOTHING
to do with ARIA.
What ARIA promotes is the implementation of keyboard interactions for
widgets that are the same or similar to those of controls in desktop
software applications
"The model for keyboard support for Web 2.0 widgets are graphical user
> interface (GUI) operating systems like Microsoft Windows, Mac OS X; and
> other desktop operating systems like GNOME and GTK. "
http://www.w3.org/WAI/PF/aria-practices/#kbd_generalnav
There is an ongoing effort to specify keyboard keystrokes to be used for web
based controls:
http://dev.aol.com/dhtml_style_guide
These keyboard interaction best practices are being implemented in
javascript UI libraries such as DOJO and JQUERY so that users can rely upon
the same or similar keystrokes being usable on for example a 'button'
regardless of whether its a native HTML button <button> or a button built
from divs and spans with added script to provide the user interaction.
>Another issue is clashes between screen reader key strokes while
>navigating a web page and assigned Aria keyboard shortcuts. The
>application element is supposed to turn off screen reader key
>functionality but this does not always seem to work properly
There is no clash per se, when in document reading mode, most key strokes
are consumed by the AT, this is why most windows based AT have a special
mode for interacting with native controls on web pages, which allows
keystrokes to be passed to the browser rather than consumed by the AT. ARIA
extends this method to the custom controls built using a combination of
HTML/scripting and CSS.
The use of role="application" on an element indicates to AT that support it
they should switch from document to application mode (so users can interact
with controls using the keyboard). It is true that it sometimes does not
work, but i would suggest it is no more or less buggy than many of the other
features in popular commercial screen readers.
you wrote:
"/basically, yopu have to expect not all users can use Aria and even
for those who can, a lot of thought needs to go in to the key mapping
and you must ensure that the user can access a simple keyboard help
overview in a convenient format somehow (perhaps have it downloadable
as a .txt file or plain html page that opens in a new window or tab)."
again what you are talking about has nothing to do with ARIA, in fact it is
the opposite:
The use of ARIA on custom controls provides users with information about the
role/state and properties of the control which typically results in the AT
providing hints about how to interact with the control.
Tests and examples of what AT report when ARIA roles are encountered:
http://www.paciellogroup.com/blog/aria-tests/user-input-widgets.html
note these results are from 18 months ago.
Regards
Stevef
2010/7/22 Birkir Rúnar Gunnarsson < = EMAIL ADDRESS REMOVED = >
> There are a few inherent problems with Aria.
> To use it I believe that you need Firefox 3.5 or newer, IE8. As for
> screen readers I think it is Jaws 10 and above, Window Eyes 7 and
above and Hal/Dolphin 11.2 and above (NVDA does a good job of
> recognizing Aria).
> You definitely cannot expect your users to be so up-to-date given the
> price of upgrades and relatively lousy set of improvements at least in
> Jaws lately (no bashing intended, Ijust feel that upgrades from Jaws 9
> have hardly been worth it).
> Another issue is clashes between screen reader key strokes while
> navigating a web page and assigned Aria keyboard shortcuts. The
> application element is supposed to turn off screen reader key
> functionality but this does not always seem to work properly (I will
> admit I lack expertees in this area, I am looking at it but this was
> discussed at length at the ICCHP conference I just attended).
> Thus a screen reader user must pass every keysroke to an Aria page
> through the screen reader by using the designed pass through key, and
> that is a relatively advanced operation (or rather, having the user
> recognize the need to do this is fairly advanced, one has to
> understand what type of page is being encounterred and what that means
> for navigation).
> Even if both of these issues are resoled and you have a user with
> compatible SR and browser and the switching off works, there is still
> a worrying lack of standards regarding keyboard mapping of aria
> elements, which means the user has to continually return to some type
> of on page help to see what keystrokes are required for what action
> (See GoogleReader as an example).
> These help messages do not (perhaps cannot) appear in a virtual
> buffer, meaning it is hard to copy them and recall them in a text
> document, so you have to kepp clicking on some type of help / overview
> on the page that tells you the functionality of each key stroke.
> There is a brilliant video demo about this, I will post it if I manage
> to dig it up from my conference lecture notes, which I will have time
> for over the weekend.
> /basically, yopu have to expect not all users can use Aria and even
> for those who can, a lot of thought needs to go in to the key mapping
> and you must ensure that the user can access a simple keyboard help
> overview in a convenient format somehow (perhaps have it downloadable
> as a .txt file or plain html page that opens in a new window or tab).
> Hope some of these thoughts help, plesae keep us updated and I will
> post back once I have sorted out my notes.
> Cheers
> -B
>
> On 7/22/10, Seth Kane < = EMAIL ADDRESS REMOVED = > wrote:
> > I have had little to no luck with ARIA unless you have the latest and
> great
> > version of both browsers and screen readers. It isn't ready for the
> lowest
> > common denominator just yet. Maybe HTML5 will be better.
> >
> >
> > Seth Kane
> >
> >
> >
From: Steven Faulkner
Date: Fri, Jul 23 2010 1:54AM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
Hi Birkir,
>The screen reader ownership survey surprises me though, it may be
>location specific, because I know the situation in a few countries in
>Europe and the user SR ownership seems to differ from this survey, so
>it is a good thing.
I am sure there are local variations, one thing we should bear in mind,
there is NVDA a free open source screen reader for windows that has
excellent support for surfing the web including ARIA support and is
available in over 20 languages many more than commercial products. Likewise
the linux screen reader Orca also has good support for ARIA.
While we must be mindful of users of older technology, we must also
adovocate users take advantage of the latest technologies especially if the
software is free (browsers and AT).
best rgeards
Steve
2010/7/22 Birkir Rúnar Gunnarsson < = EMAIL ADDRESS REMOVED = >
> Steve
>
> Thanks very much for all the info.
> Like I said I am fairly new to all of this and it appears I
> misunderstood a few things, but I am all too happy to be corrected and
> will start with the pointers in your post for further research.
> The screen reader ownership survey surprises me though, it may be
> location specific, because I know the situation in a few countries in
> Europe and the user SR ownership seems to differ from this survey, so
> it is a good thing.
> I will post back with questions/comments after I update my knowledge
> some. *grin*
> Cheers
> -B
>
> On 7/22/10, Steven Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> > hi birkir,
> >
> > you wrote:
> > "You definitely cannot expect your users to be so up-to-date given the
> price
> > of upgrades..."
> >
> > The webaim screen readers survey differs from your conclusion
> >
> > "The vast majority of respondents updated their primary screen reader
> within
> > the previous year."
> > http://www.webaim.org/projects/screenreadersurvey2/#demographics
> >
> >
> > you wrote:
> > "Another issue is clashes between screen reader key strokes while
> > navigating a web page and assigned Aria keyboard shortcuts. "
> >
> > There are no "ARIA keyboard shortcuts" as such:
> > The set of keyboard shortcuts defined for use in Google Reader has
> NOTHING
> > to do with ARIA.
> >
> > What ARIA promotes is the implementation of keyboard interactions for
> > widgets that are the same or similar to those of controls in desktop
> > software applications
> >
> > "The model for keyboard support for Web 2.0 widgets are graphical user
> >> interface (GUI) operating systems like Microsoft Windows, Mac OS X; and
> >> other desktop operating systems like GNOME and GTK. "
> >
> > http://www.w3.org/WAI/PF/aria-practices/#kbd_generalnav
> >
> > There is an ongoing effort to specify keyboard keystrokes to be used for
> web
> > based controls:
> > http://dev.aol.com/dhtml_style_guide
> >
> > These keyboard interaction best practices are being implemented in
> > javascript UI libraries such as DOJO and JQUERY so that users can rely
> upon
> > the same or similar keystrokes being usable on for example a 'button'
> > regardless of whether its a native HTML button <button> or a button built
> > from divs and spans with added script to provide the user interaction.
> >
> >>Another issue is clashes between screen reader key strokes while
> >>navigating a web page and assigned Aria keyboard shortcuts. The
> >>application element is supposed to turn off screen reader key
> >>functionality but this does not always seem to work properly
> >
> > There is no clash per se, when in document reading mode, most key strokes
> > are consumed by the AT, this is why most windows based AT have a special
> > mode for interacting with native controls on web pages, which allows
> > keystrokes to be passed to the browser rather than consumed by the AT.
> ARIA
> > extends this method to the custom controls built using a combination of
> > HTML/scripting and CSS.
> >
> > The use of role="application" on an element indicates to AT that support
> it
> > they should switch from document to application mode (so users can
> interact
> > with controls using the keyboard). It is true that it sometimes does not
> > work, but i would suggest it is no more or less buggy than many of the
> other
> > features in popular commercial screen readers.
> >
> > you wrote:
> > "/basically, yopu have to expect not all users can use Aria and even
> > for those who can, a lot of thought needs to go in to the key mapping
> > and you must ensure that the user can access a simple keyboard help
> > overview in a convenient format somehow (perhaps have it downloadable
> > as a .txt file or plain html page that opens in a new window or tab)."
> >
> > again what you are talking about has nothing to do with ARIA, in fact it
> is
> > the opposite:
> > The use of ARIA on custom controls provides users with information about
> the
> > role/state and properties of the control which typically results in the
> AT
> > providing hints about how to interact with the control.
> >
> > Tests and examples of what AT report when ARIA roles are encountered:
> > http://www.paciellogroup.com/blog/aria-tests/user-input-widgets.html
> > note these results are from 18 months ago.
> >
> > Regards
> > Stevef
> >
> >
> >
> > 2010/7/22 Birkir Rúnar Gunnarsson < = EMAIL ADDRESS REMOVED = >
> >
> >> There are a few inherent problems with Aria.
> >> To use it I believe that you need Firefox 3.5 or newer, IE8. As for
> >> screen readers I think it is Jaws 10 and above, Window Eyes 7 and
> >
> > above and Hal/Dolphin 11.2 and above (NVDA does a good job of
> >> recognizing Aria).
> >> You definitely cannot expect your users to be so up-to-date given the
> >> price of upgrades and relatively lousy set of improvements at least in
> >> Jaws lately (no bashing intended, Ijust feel that upgrades from Jaws 9
> >> have hardly been worth it).
> >> Another issue is clashes between screen reader key strokes while
> >> navigating a web page and assigned Aria keyboard shortcuts. The
> >> application element is supposed to turn off screen reader key
> >> functionality but this does not always seem to work properly (I will
> >> admit I lack expertees in this area, I am looking at it but this was
> >> discussed at length at the ICCHP conference I just attended).
> >> Thus a screen reader user must pass every keysroke to an Aria page
> >> through the screen reader by using the designed pass through key, and
> >> that is a relatively advanced operation (or rather, having the user
> >> recognize the need to do this is fairly advanced, one has to
> >> understand what type of page is being encounterred and what that means
> >> for navigation).
> >> Even if both of these issues are resoled and you have a user with
> >> compatible SR and browser and the switching off works, there is still
> >> a worrying lack of standards regarding keyboard mapping of aria
> >> elements, which means the user has to continually return to some type
> >> of on page help to see what keystrokes are required for what action
> >> (See GoogleReader as an example).
> >> These help messages do not (perhaps cannot) appear in a virtual
> >> buffer, meaning it is hard to copy them and recall them in a text
> >> document, so you have to kepp clicking on some type of help / overview
> >> on the page that tells you the functionality of each key stroke.
> >> There is a brilliant video demo about this, I will post it if I manage
> >> to dig it up from my conference lecture notes, which I will have time
> >> for over the weekend.
> >> /basically, yopu have to expect not all users can use Aria and even
> >> for those who can, a lot of thought needs to go in to the key mapping
> >> and you must ensure that the user can access a simple keyboard help
> >> overview in a convenient format somehow (perhaps have it downloadable
> >> as a .txt file or plain html page that opens in a new window or tab).
> >> Hope some of these thoughts help, plesae keep us updated and I will
> >> post back once I have sorted out my notes.
> >> Cheers
> >> -B
> >>
> >> On 7/22/10, Seth Kane < = EMAIL ADDRESS REMOVED = > wrote:
> >> > I have had little to no luck with ARIA unless you have the latest and
> >> great
> >> > version of both browsers and screen readers. It isn't ready for the
> >> lowest
> >> > common denominator just yet. Maybe HTML5 will be better.
> >> >
> >> >
> >> > Seth Kane
> >> >
> >> >
> >> >
From: Hoffman, Allen
Date: Mon, Jul 26 2010 2:42PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
Just curious:
Dojo and Jquery are the two always named sets of building blocks which include ARIA.
Of the set of similar building blocks, is this 2% 50% or what?
This proliferation of such building block sets which may or may not include easy use of accessibility features seems to be a real challenge to me.
From: Patrick H. Lauke
Date: Mon, Jul 26 2010 4:03PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
also worth mentioning yahoo!'s YUI work there
--
Patrick H. Lauke
On 26 Jul 2010, at 21:39, "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = > wrote:
> Just curious:
> Dojo and Jquery are the two always named sets of building blocks which include ARIA.
> Of the set of similar building blocks, is this 2% 50% or what?
> This proliferation of such building block sets which may or may not include easy use of accessibility features seems to be a real challenge to me.
>
>
>
>
From: Birkir Rúnar Gunnarsson
Date: Mon, Jul 26 2010 4:24PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
This is true, and this is why I think usability testing, in general,
should be done with NVDA rather than with the commercial screen
readers, or, at least, alongside the major screen readers.
I am very impressed with the NVDA performance, especially in this area.
Cheers
-B
On 7/26/10, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> also worth mentioning yahoo!'s YUI work there
>
> --
> Patrick H. Lauke
>
>
> On 26 Jul 2010, at 21:39, "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Just curious:
>> Dojo and Jquery are the two always named sets of building blocks which
>> include ARIA.
>> Of the set of similar building blocks, is this 2% 50% or what?
>> This proliferation of such building block sets which may or may not
>> include easy use of accessibility features seems to be a real challenge to
>> me.
>>
>>
>>
>>
From: patrick dunphy
Date: Mon, Jul 26 2010 6:42PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
Correct me if I'm wrong but there's Aria support as of YUI 2.7 but
not 3.0 yet as it was a major overhaul.
Thanks!
-PD
On 2010-07-26, at 6:02 PM, "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
wrote:
> also worth mentioning yahoo!'s YUI work there
>
> --
> Patrick H. Lauke
>
>
> On 26 Jul 2010, at 21:39, "Hoffman, Allen" < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Just curious:
>> Dojo and Jquery are the two always named sets of building blocks
>> which include ARIA.
>> Of the set of similar building blocks, is this 2% 50% or what?
>> This proliferation of such building block sets which may or may not
>> include easy use of accessibility features seems to be a real
>> challenge to me.
>>
>>
>>
>>
From: Julie Romanowski
Date: Tue, Jul 27 2010 5:09AM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
YUI 3 has had ARIA support since the YUI 3.0.0 beta 1 version release in 2009.
From: patrick dunphy
Date: Tue, Jul 27 2010 6:45AM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
Thanks for the correction Julie.
Thanks!
-PD
On 2010-07-27, at 7:05 AM, "Julie Romanowski" < = EMAIL ADDRESS REMOVED =
> wrote:
> YUI 3 has had ARIA support since the YUI 3.0.0 beta 1 version
> release in 2009.
>
>
From: Michael.Moore
Date: Tue, Jul 27 2010 7:39AM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
Why would you consider user testing with a screen reader that is not yet widely used to be useful? I agree that NVDA has better support for ARIA at this time than the main stream screen readers. But using NVDA for user testing for visually impaired users would be like relying on Arora as your browser for user testing for non-disabled users.
Mike Moore
(512) 424-4159
From: Christophe Strobbe
Date: Tue, Jul 27 2010 7:51AM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
At 13:05 27/07/2010, Julie Romanowski wrote:
>YUI 3 has had ARIA support since the YUI 3.0.0 beta 1 version
>release in 2009.
Where is this documented? How much WAI-ARIA support?
When I looked at YUI 2 in March this year, only Button, Carousel,
Container, Menu and TabView had examples with an ARIA plugin (and
Grids CSS had an example of using landmark roles), which is less than
a third of the YUI 2 widgets. YUI 2 ProgressBar also supports
WAI-ARIA <http://developer.yahoo.com/yui/progressbar/#aria>;.
YUI 3 has three examples that use the focus manager node plugin (see
<http://developer.yahoo.com/yui/3/examples/>;): Accessible Toolbar,
Accessible TabView and Accessible Menu Button. However, when you look
at the documentation of the component infrastructure
(<http://developer.yahoo.com/yui/3/#infra>;) or the widgets (three
widgets, all in beta), a search for ARIA brings up nothing. The
documentation of the MenuNav Node Plugin
(<http://developer.yahoo.com/yui/3/node-menunav/>;) also mentions
WAI-ARIA support.
Can anyone provide more specific pointers on WAI-ARIA support in YUI 3?
Christophe
PS: It is possible to use YUI 2 widgets in YUI 3. See
<http://developer.yahoo.com/yui/3/examples/yui/yui-compat.html>; and
<http://ericmiraglia.com/yui/demos/2in3dt.php>;. This way, you should
also be able to use the YUI 2 widgets with WAI-ARIA support in YUI 3.
>
From: Steven Faulkner
Date: Tue, Jul 27 2010 7:54AM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
Hi Michael,
>Why would you consider user testing with a screen reader that is not yet
widely used to be useful?
according to the latest webaim screen reader survey NVDA is commonly used by
25% of respondents.
Also it is a screen reader that is much more widley available than other
screen readers (localized into 20+ languages) and is free.
regards
steve
On 27 July 2010 14:36, < = EMAIL ADDRESS REMOVED = > wrote:
> Why would you consider user testing with a screen reader that is not yet
> widely used to be useful? I agree that NVDA has better support for ARIA at
> this time than the main stream screen readers. But using NVDA for user
> testing for visually impaired users would be like relying on Arora as your
> browser for user testing for non-disabled users.
>
> Mike Moore
> (512) 424-4159
>
>
>
From: info
Date: Tue, Jul 27 2010 9:00AM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
> Can anyone provide more specific pointers on WAI-ARIA support in YUI 3?
Would this be of useful?
http://www.yuiblog.com/blog/2009/08/03/aria-made-easier-with-yui-3/
Thanks,
From: Christophe Strobbe
Date: Tue, Jul 27 2010 10:09AM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
At 16:58 27/07/2010, = EMAIL ADDRESS REMOVED = wrote:
> > Can anyone provide more specific pointers on WAI-ARIA support in YUI 3?
>Would this be of useful?
>http://www.yuiblog.com/blog/2009/08/03/aria-made-easier-with-yui-3/
I had seen this. The article shows, for example, how you can easily
add a role to a custom widget. It does not add new information about
ARIA support in YUI 3's own widgets (the ones I mentioned in my
previous message). If you search the code for the Slider widget for
'role', you get nothing. There is also no mention of role in the JS
code for Overlay - because it is a generic widget. The newer TabView
widget in YUI 3.1.1 has a role = tablist (line 195 in tabview.js).
If you want a slider with WAI-ARIA role = slider, it seems you need
that add that role by yourself. As far as I can tell, even reusing
the YUI 2 Slider in YUI 3 won't help.
Best regards,
Christophe
>Thanks,
>
>
>
From: Léonie Watson
Date: Tue, Jul 27 2010 10:39AM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
"Why would you consider user testing with a screen reader that is not yet widely used to be useful? I agree that NVDA has better support for ARIA at this time than the main stream screen readers. But using NVDA for user testing for visually impaired users would be like relying on Arora as your browser for user testing for non-disabled users."
NVDA is rapidly growing in popularity. Whilst it lacks some of the functionality that other screen readers provide, it's increasingly used as a backup option and in time I think we'll see it gain primary ground as well.
Jaws is undoubtedly the most popular primary option, but the Webaim survey reports that 49% of people use more than one screen reader. Of the alternatives, NVDA is the most popular with nearly 26% of people choosing it.
http://webaim.org/projects/screenreadersurvey2/
Regards,
Léonie.
--
Nomensa - humanising technology
Léonie Watson | Director of Accessibility
t. +44 (0)117 929 7333
From: Michael.Moore
Date: Tue, Jul 27 2010 1:06PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
" NVDA is rapidly growing in popularity. Whilst it lacks some of the functionality that other screen readers provide, it's increasingly used as a backup option and in time I think we'll see it gain primary ground as well.
Jaws is undoubtedly the most popular primary option, but the WebAIM survey reports that 49% of people use more than one screen reader. Of the alternatives, NVDA is the most popular with nearly 26% of people choosing it.
http://webaim.org/projects/screenreadersurvey2/"
I am very familiar with the results of the WebAIM survey. I was one of the respondents. I think that the survey supports my view that NVDA in most cases it is not the best platform for user testing. Only 3% of respondents listed NVDA as their primary screen reader. I believe that user testing should be conducted using the user's primary screen reader and browser combination unless you are testing for use in a closed environment where the user will not have a choice of platform, including their OS, AT and other software.
I believe that there is a risk in assuming that the population of survey respondents is fully representative of screen reader users in general. My gut instinct is that the population may have been a bit more tech savvy. For example 10% of the respondents reported that they do not have a disability. I would be very surprised to find that 10% of JAWS users do not have a disability. I would also expect that 10% is heavily concentrated among accessibility experts. Even among the 90% of respondents who reported a disability I would not be surprised to learn that there was a disproportionate representation of folks who could be considered technology and/or accessibility experts. I am not suggesting that the results of the survey are invalid, just that some of the more surprising findings such as use of multiple screen readers, and recent updates of AT may not truly reflect the screen reader user population in general.
NVDA is a good tool for troubleshooting problems. It helps us confirm when problems are related to the AT and not the application, document, or system under test. We are starting a pilot program to evaluate NVDA and/or SAToGo as a supplemental assistive technology for our staff who use a screen reader. Since most of our staff who use a screen reader are not technologists and most could be considered "average" in their computer skills, it will be interesting to get their feedback on the usefulness of a second screen reader.
Mike Moore
From: Phil Teare
Date: Tue, Jul 27 2010 1:51PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
Anyone know a screen-reader I can use on a mac that recognizes Aria live
regions?
Cheers
Phil
Phil Teare,
On 27 July 2010 20:05, < = EMAIL ADDRESS REMOVED = > wrote:
> " NVDA is rapidly growing in popularity. Whilst it lacks some of the
> functionality that other screen readers provide, it's increasingly used as a
> backup option and in time I think we'll see it gain primary ground as well.
>
> Jaws is undoubtedly the most popular primary option, but the WebAIM
> survey reports that 49% of people use more than one screen reader. Of the
> alternatives, NVDA is the most popular with nearly 26% of people choosing
> it.
> http://webaim.org/projects/screenreadersurvey2/"
>
> I am very familiar with the results of the WebAIM survey. I was one of the
> respondents. I think that the survey supports my view that NVDA in most
> cases it is not the best platform for user testing. Only 3% of respondents
> listed NVDA as their primary screen reader. I believe that user testing
> should be conducted using the user's primary screen reader and browser
> combination unless you are testing for use in a closed environment where the
> user will not have a choice of platform, including their OS, AT and other
> software.
>
> I believe that there is a risk in assuming that the population of survey
> respondents is fully representative of screen reader users in general. My
> gut instinct is that the population may have been a bit more tech savvy. For
> example 10% of the respondents reported that they do not have a disability.
> I would be very surprised to find that 10% of JAWS users do not have a
> disability. I would also expect that 10% is heavily concentrated among
> accessibility experts. Even among the 90% of respondents who reported a
> disability I would not be surprised to learn that there was a
> disproportionate representation of folks who could be considered technology
> and/or accessibility experts. I am not suggesting that the results of the
> survey are invalid, just that some of the more surprising findings such as
> use of multiple screen readers, and recent updates of AT may not truly
> reflect the screen reader user population in general.
>
> NVDA is a good tool for troubleshooting problems. It helps us confirm when
> problems are related to the AT and not the application, document, or system
> under test. We are starting a pilot program to evaluate NVDA and/or SAToGo
> as a supplemental assistive technology for our staff who use a screen
> reader. Since most of our staff who use a screen reader are not
> technologists and most could be considered "average" in their computer
> skills, it will be interesting to get their feedback on the usefulness of a
> second screen reader.
>
> Mike Moore
>
>
>
From: Birkir Rúnar Gunnarsson
Date: Tue, Jul 27 2010 2:06PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
Michael
My point regarding the ability of NVDA to recognize certain things and
its potential as a usability screen reader, is mostly that if NVDA
support a given feature it is available to any user who really needs
it, free of charge. In Iceland we support a lot of users and have come
across web browsing problems with other major screen readers, in those
situations we download NVDA for the user and show the user how to use
it as a stop gap while the other SR is being fixed. This way we can
definitely say a user that has to access page X can do so
independently. If the alternative was to, say, by Jaws for a Hal user
who cannot access page X or document Y, that is an expensive and
lengthy procedure and we cannot really justify that to our purchasing
department, and hence we cannot say that the page is accessible with
screen reader Hal (this is merely a hypothetical scenario, feel free
to insert any other combination of screen readers herein).
We have been doing evaluation on NVDA with a lot of common user tasks
and would be happy to share our findings with you off-list if you
think it would be useful. Your sample of an accessible pdf form has
helped us tremensously so if I/we can repay the favour just ask, But
that is getting a bit off topic.
I feel usability testing is to estimate whether the user can, through
current software or free software changes (upgrade to browser/open
source screen reading) access and work with an object. I am far from
being an expert so this may be a wrong approach to usability theory.
Perhaps the WebAim survey is representative of the types of users who
would be likely to encounter, and interact with, Aria content though.
It is very likely that the majority of users who are elderly or not
very computer savvy will come across many Aria pages any time soon,
though even the most likely pages for an infrequent user to serve
would be social sites, such as FaceBook, I suppose.
Cheers
-Birkir
On 7/27/10, Phil Teare < = EMAIL ADDRESS REMOVED = > wrote:
> Anyone know a screen-reader I can use on a mac that recognizes Aria live
> regions?
>
>
> Cheers
> Phil
>
>
> Phil Teare,
>
>
>
> On 27 July 2010 20:05, < = EMAIL ADDRESS REMOVED = > wrote:
>
>> " NVDA is rapidly growing in popularity. Whilst it lacks some of the
>> functionality that other screen readers provide, it's increasingly used as
>> a
>> backup option and in time I think we'll see it gain primary ground as
>> well.
>>
>> Jaws is undoubtedly the most popular primary option, but the
>> WebAIM
>> survey reports that 49% of people use more than one screen reader. Of the
>> alternatives, NVDA is the most popular with nearly 26% of people choosing
>> it.
>> http://webaim.org/projects/screenreadersurvey2/"
>>
>> I am very familiar with the results of the WebAIM survey. I was one of the
>> respondents. I think that the survey supports my view that NVDA in most
>> cases it is not the best platform for user testing. Only 3% of respondents
>> listed NVDA as their primary screen reader. I believe that user testing
>> should be conducted using the user's primary screen reader and browser
>> combination unless you are testing for use in a closed environment where
>> the
>> user will not have a choice of platform, including their OS, AT and other
>> software.
>>
>> I believe that there is a risk in assuming that the population of survey
>> respondents is fully representative of screen reader users in general. My
>> gut instinct is that the population may have been a bit more tech savvy.
>> For
>> example 10% of the respondents reported that they do not have a
>> disability.
>> I would be very surprised to find that 10% of JAWS users do not have a
>> disability. I would also expect that 10% is heavily concentrated among
>> accessibility experts. Even among the 90% of respondents who reported a
>> disability I would not be surprised to learn that there was a
>> disproportionate representation of folks who could be considered
>> technology
>> and/or accessibility experts. I am not suggesting that the results of the
>> survey are invalid, just that some of the more surprising findings such as
>> use of multiple screen readers, and recent updates of AT may not truly
>> reflect the screen reader user population in general.
>>
>> NVDA is a good tool for troubleshooting problems. It helps us confirm when
>> problems are related to the AT and not the application, document, or
>> system
>> under test. We are starting a pilot program to evaluate NVDA and/or SAToGo
>> as a supplemental assistive technology for our staff who use a screen
>> reader. Since most of our staff who use a screen reader are not
>> technologists and most could be considered "average" in their computer
>> skills, it will be interesting to get their feedback on the usefulness of
>> a
>> second screen reader.
>>
>> Mike Moore
>>
>>
>>
From: Michael.Moore
Date: Tue, Jul 27 2010 2:24PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
A post on Marco's Accessibility blog suggests that this may be possible with VoiceOver when running Snow Leopard. The post is about IoS4 but he mentions VoiceOver and Snow Leopard about 2/3 of the way down the page. I will need to wait till I get home to test - Windows world here.
The url for the post is: http://www.marcozehe.de/2010/06/22/apples-ios-4-supports-wai-aria-landmarks/
Mike Moore
(512) 424-4159
From: Claudia.Case
Date: Tue, Jul 27 2010 2:30PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
A note about ARIA working code examples... Not all ARIA widgets are created equal!
About 3 months ago, I tested a number of publicly available working code examples. I focused my testing on each widgets' semantic accuracy (role/properties/states) and keyboard operation vis-a-vis the design pattern guidelines in WAI-ARIA's Authoring Practices (http://www.w3.org/TR/wai-aria-practices/#aria_ex).
Here's a list of the examples that had a high-level of conformance with the WAI-ARIA design pattern guidelines, both semantically and in keyboard operation:
CodeTalks | Date Picker example
Dojo | Button/Button Menu example
Dojo | Dialog (modal) example
Frequency-Decoder | Date Picker example
Google Web Toolkit | Rich Text example
Google Web Toolkit | TreeView example
YUI 2 | Container example
YUI 2 | Menu example
YUI 2 | TabView example
Here's a list of the examples that did a less than stellar job conforming to the guidelines:
YUI 2 | Button example
YUI 2 | Carousel example
Google Web Toolkit | Date Picker example
Google Web Toolkit | Menu example
I want to reiterate that these results are 3 months old. In the future, I plan to repeat the testing using Firefox 3.6 and IE8 and I expect those tests to yield even better results.
claudia
From: ckrugman
Date: Tue, Jul 27 2010 2:39PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →
As a screen reader user I would not consider those valid grounds for testing
purposes. The criteria especially that it is free is not a subjective
requirement to ascertain usage. I think I would stick with the tried and
true that has been around for testing purposes to insure compliance. It is
disappointing to even think that web designers would consider compromising
testing standards in this manner.
chuck
----- Original Message -----
From: "Steven Faulkner" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, July 27, 2010 6:41 AM
Subject: Re: [WebAIM] Wai Aria how useful?
Hi Michael,
>Why would you consider user testing with a screen reader that is not yet
widely used to be useful?
according to the latest webaim screen reader survey NVDA is commonly used by
25% of respondents.
Also it is a screen reader that is much more widley available than other
screen readers (localized into 20+ languages) and is free.
regards
steve
On 27 July 2010 14:36, < = EMAIL ADDRESS REMOVED = > wrote:
> Why would you consider user testing with a screen reader that is not yet
> widely used to be useful? I agree that NVDA has better support for ARIA at
> this time than the main stream screen readers. But using NVDA for user
> testing for visually impaired users would be like relying on Arora as your
> browser for user testing for non-disabled users.
>
> Mike Moore
> (512) 424-4159
>
>
>
From: Ron Stewart
Date: Tue, Jul 27 2010 3:06PM
Subject: Re: Wai Aria how useful?
← Previous message | No next message
What testing standards are you referring too, what is tried and true?
Testing with a specific AT product, in this case a brand of screen reader
does not insure any concrete measure of accessibility it only insure
compliance with that particular products approach to access in a given
operating systems with a given set of products.
Ron Stewart