WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Testing with Screen Readers (was RE: Wai Aria how useful?)

for

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

From: John Foliot
Date: Tue, Jul 27 2010 5:21PM
Subject: Testing with Screen Readers (was RE: Wai Aria how useful?)
No previous message | Next message →

Interesting thread, and some thoughts:

There is a real tension between building standards compliant sites that
work with all technologies versus 'testing' with one tool, and building in
hacks and other 'repair strategies' to support bad software. Just ask
those unfortunates who must still support IE6. If you really must test
with a screen reader, then test with more than one: you test with more
than one browser, right?

The other point that must be considered is that to really be able to
'test' with any screen-reader, you should be a daily screen-reader user.
The problem we have is developers who want to do the right thing, but are
not competent with using Adaptive Technology, so really, all they are
doing is listening to their site read aloud: they are often missing out on
much of the interactivity daily users apply to using their software. For
production class developers, they are often better served by asking (and
paying) daily AT users to do the testing for them, rather than pretending
that opening up NVDA, or the time-crippled JAWs eval copy (which is
illegal, but...) and listening to a site read aloud and calling it
"testing".

Finally, as a very real question, what exactly are you testing *for* when
using a screen reader? If a developer is testing to find holes, I would
suggest they are approaching the problem from the wrong angle: you should
be testing that solutions implemented work as desired. So the developer
should be thinking about the problems and solutions long before they get
to the functional testing stage, and there are plenty of developer tools
out there that can confirm if your code is moving in the right direction
(understanding how a DOM inspector works is crucial); achieving real
accessible content means making some decisions at the foundational stage -
it's architectural. Waiting for a walk-through using AT to find problems
is almost certainly a recipe for ensuring there will be problems to
find...


As always, IMHO

JF



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:webaim-forum-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of = EMAIL ADDRESS REMOVED =
> Sent: Tuesday, July 27, 2010 1:37 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Wai Aria how useful?
>
> 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
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED = [mailto:
> > = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir Rúnar
> Gunnarsson
> > Sent: Monday, July 26, 2010 5:21 PM
> > To: WebAIM Discussion List
> > Subject: Re: [WebAIM] Wai Aria how useful?
> >
> > 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.
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Birkir Rúnar Gunnarsson [mailto: = EMAIL ADDRESS REMOVED = ]
> > >> Sent: Thursday, July 22, 2010 6:43 PM
> > >> To: WebAIM Discussion List
> > >> Subject: Re: [WebAIM] Wai Aria how useful?
> > >>
> > >> 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
> > >>>>>
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: = EMAIL ADDRESS REMOVED =
> > >>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > >>>>> = EMAIL ADDRESS REMOVED =
> > >>>>> Sent: Wednesday, July 21, 2010 2:13 PM
> > >>>>> To: WebAIM Discussion List
> > >>>>> Subject: Re: [WebAIM] Wai Aria how useful?
> > >>>>>
> > >>>>> 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: ckrugman@sbcglobal.net
Date: Tue, Jul 27 2010 6:42PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →

It is also important to note that here in the U.S. most rehab agencies will
provide JAWS or Window Eyes for their rehab clients who are receiving
equipment.
Chuck
----- Original Message -----
From: < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, July 27, 2010 12:05 PM
Subject: Re: [WebAIM] Wai Aria how useful?


>" 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: ckrugman@sbcglobal.net
Date: Tue, Jul 27 2010 7:03PM
Subject: Re: Wai Aria how useful?
← Previous message | Next message →

As a user I am referring to the need to test using multiple products to
replicate the actual operating conditions of screen reader users that will
be experienced in the individual setting. Tried and true standards refer to
the widely accessible products that are used on a regular basis by a large
number of screen reader users. In other words the tried and true standards
refer to widely available products that are used e.g. Jaws and Window Eyes
and that testing needs to occur using multiple screen readers to insure
total accessibility.
chuck
----- Original Message -----
From: "Ron Stewart" < = EMAIL ADDRESS REMOVED = >
To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, July 27, 2010 2:03 PM
Subject: Re: [WebAIM] Wai Aria how useful?


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

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
= EMAIL ADDRESS REMOVED =
Sent: Tuesday, July 27, 2010 4:37 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Wai Aria how useful?

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
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir Rúnar Gunnarsson
> Sent: Monday, July 26, 2010 5:21 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Wai Aria how useful?
>
> 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.
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Birkir Rúnar Gunnarsson [mailto: = EMAIL ADDRESS REMOVED = ]
> >> Sent: Thursday, July 22, 2010 6:43 PM
> >> To: WebAIM Discussion List
> >> Subject: Re: [WebAIM] Wai Aria how useful?
> >>
> >> 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
> >>>>>
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: = EMAIL ADDRESS REMOVED =
> >>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> >>>>> = EMAIL ADDRESS REMOVED =
> >>>>> Sent: Wednesday, July 21, 2010 2:13 PM
> >>>>> To: WebAIM Discussion List
> >>>>> Subject: Re: [WebAIM] Wai Aria how useful?
> >>>>>
> >>>>> 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: Langum, Michael J
Date: Wed, Jul 28 2010 6:48AM
Subject: Re: Testing with Screen Readers (was RE: Wai Aria how useful?)
← Previous message | Next message →

John writes:
> The other point that must be considered is that to really be able to 'test' with any screen-reader,
> you should be a daily screen-reader user. ....

I agree in principle, but in the "real world" time and resources do not permit the additional time and cost of testing by "a daily screen-reader user."

I am only able to do detailed testing at the code level (e.g. "alt" text; semantic structure; <label> for <input>, column and row headers, etc. We do randomized testing on some content, and react immediately if we get any user complaints.

Jared, Do you think there might be value in doing a survey on testing methodologies? Do developers actually test? Do they go beyond the use of automated testing tools? Do they do "functional" testing with various AT products? Do they do this functional testing on each file developed?

-- Mike




> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:webaim-forum-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of = EMAIL ADDRESS REMOVED =
> Sent: Tuesday, July 27, 2010 1:37 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Wai Aria how useful?
>
> 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
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED = [mailto:
> > = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir Rúnar
> Gunnarsson
> > Sent: Monday, July 26, 2010 5:21 PM
> > To: WebAIM Discussion List
> > Subject: Re: [WebAIM] Wai Aria how useful?
> >
> > 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.
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Birkir Rúnar Gunnarsson
> > >> [mailto: = EMAIL ADDRESS REMOVED = ]
> > >> Sent: Thursday, July 22, 2010 6:43 PM
> > >> To: WebAIM Discussion List
> > >> Subject: Re: [WebAIM] Wai Aria how useful?
> > >>
> > >> 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
> > >>>>>
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: = EMAIL ADDRESS REMOVED =
> > >>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > >>>>> = EMAIL ADDRESS REMOVED =
> > >>>>> Sent: Wednesday, July 21, 2010 2:13 PM
> > >>>>> To: WebAIM Discussion List
> > >>>>> Subject: Re: [WebAIM] Wai Aria how useful?
> > >>>>>
> > >>>>> 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: Birkir Rúnar Gunnarsson
Date: Wed, Jul 28 2010 7:00AM
Subject: Re: Testing with Screen Readers (was RE: Wai Aria how useful?)
← Previous message | Next message →

At the conference I attended in Vienna (and some of you attended as
well, I believe) there was talk about the need for screen reader/AT
software simulation tools or plug ins for development environments, so
the developers get a feel for the problem and how their code would
work for a screen reader user.
It is an interesting idea, though there are some limitations, e.g.
that one should expect an SR user, or user of any other AT, to have
developed some skills with the product and be able to do more with it
than, perhaps, a developer would see at first glance.
Also building accessibility testing and compliance into CMS and other
development software would definitely, I think, be a very good step,
and I know there are projects going on in the area.
I see the practical problem of testing with real users, it is
expensive, there are marked differences in what each screen reader
does well and does badly, so you might need different testing based on
your potential user group etc.
Sometimes a particular SR has not implemented technology that exists,
and it is hard for the developer to do anything about it.
Cheers
-B

On 7/28/10, Langum, Michael J < = EMAIL ADDRESS REMOVED = > wrote:
> John writes:
>> The other point that must be considered is that to really be able to
>> 'test' with any screen-reader,
>> you should be a daily screen-reader user. ....
>
> I agree in principle, but in the "real world" time and resources do not
> permit the additional time and cost of testing by "a daily screen-reader
> user."
>
> I am only able to do detailed testing at the code level (e.g. "alt" text;
> semantic structure; <label> for <input>, column and row headers, etc. We do
> randomized testing on some content, and react immediately if we get any user
> complaints.
>
> Jared, Do you think there might be value in doing a survey on testing
> methodologies? Do developers actually test? Do they go beyond the use of
> automated testing tools? Do they do "functional" testing with various AT
> products? Do they do this functional testing on each file developed?
>
> -- Mike
>
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED = [mailto:webaim-forum-
>> = EMAIL ADDRESS REMOVED = ] On Behalf Of = EMAIL ADDRESS REMOVED =
>> Sent: Tuesday, July 27, 2010 1:37 PM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Wai Aria how useful?
>>
>> 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
>> >
>> >
>> > -----Original Message-----
>> > From: = EMAIL ADDRESS REMOVED = [mailto:
>> > = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir Rúnar
>> Gunnarsson
>> > Sent: Monday, July 26, 2010 5:21 PM
>> > To: WebAIM Discussion List
>> > Subject: Re: [WebAIM] Wai Aria how useful?
>> >
>> > 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.
>> > >>
>> > >>
>> > >>
>> > >> -----Original Message-----
>> > >> From: Birkir Rúnar Gunnarsson
>> > >> [mailto: = EMAIL ADDRESS REMOVED = ]
>> > >> Sent: Thursday, July 22, 2010 6:43 PM
>> > >> To: WebAIM Discussion List
>> > >> Subject: Re: [WebAIM] Wai Aria how useful?
>> > >>
>> > >> 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
>> > >>>>>
>> > >>>>>
>> > >>>>> -----Original Message-----
>> > >>>>> From: = EMAIL ADDRESS REMOVED =
>> > >>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>> > >>>>> = EMAIL ADDRESS REMOVED =
>> > >>>>> Sent: Wednesday, July 21, 2010 2:13 PM
>> > >>>>> To: WebAIM Discussion List
>> > >>>>> Subject: Re: [WebAIM] Wai Aria how useful?
>> > >>>>>
>> > >>>>> 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: Jared Smith
Date: Wed, Jul 28 2010 8:39AM
Subject: Re: Testing with Screen Readers (was RE: Wai Aria how useful?)
← Previous message | Next message →

On Wed, Jul 28, 2010 at 6:47 AM, Langum, Michael J wrote:

> Jared,  Do you think there might be value in doing a survey on testing methodologies?

Yes. Stay tuned. ;-)

I don't think that develop testing in screen readers is useless.
There's a lot that can be gained by simply listening to your page in a
screen reader. Of course most of the things that can be identified
this way can also be identified through automated tools, particularly
something like the Text-only View in WAVE, which approximates what a
screen reader might read.

Screen reader testing best identifies interaction and structural
issues that aren't apparent visually or even through reading through
the page. Thus it becomes more vital for more interactive pages.
Fortunately, it's not overly difficult to learn how to use screen
readers to do basic interaction. We have articles for JAWS
(http://webaim.org/articles/jaws/), NVDA
(http://webaim.org/articles/nvda/), and (very soon) VoiceOver to get
you started.

Three additional points:

- Screen reader testing should be but one aspect of a broader
evaluation methodology.

- Some caution needs to be employed in blind screen reader testing.
How do they know if something is inaccessible if it's inaccessible?
It's quite possible that something could be skipped entirely and they
may not even know it. Watching the screen reader tester interact with
the page is very valuable.

- Be careful with accessibility testing with screen reader users.
Instead, conduct usability testing with many users, including screen
reader users. If you focus only on accessibility issues (this image
has poor alt text, this text box is missing a label, etc.) you could
end up with a very technically accessible web site that is entirely
unusable as a whole to screen reader users.

Jared Smith
WebAIM

From: Michael.Moore@dars.state.tx.us
Date: Wed, Jul 28 2010 8:42AM
Subject: Re: Testing with Screen Readers (was RE: Wai Aria how useful?)
← Previous message | No next message

Excellent summation of the issue and the considerations John. For whatever its worth to the conversation I will share our testing protocol as a real world example. Assuming that working for a state agency is considered to be the real world.

1. Test for accessibility standards compliance. We use section 508 since this is what is required by Texas law for a state agency. (Hardware, software, office equipment, telecommunications, web and electronic documents) An important note here is that for most vendor generated content and applications this is the limit of what they are contractually bound to do.
2. Test for valid markup. We use W3C validation for HTML/CSS. Unfortunately we often make exceptions here because the authoring tools/CMS systems used do not generate valid code - e.g. MS SharePoint (Exceptions are not made for public content)
3. Test for proper document structure. Headings, lists, tables etc. Again it is occasionally necessary to make exceptions particularly for systems that rely on Table layout for the interface components - e.g. PeopleSoft (Exceptions are not made for public content)
4. Test with agency standard assistive technology. For screen readers this is currently JFW 9 on Windows XP SP3 with IE7 for web content, Adobe Reader 9 for PDF, and MS Office 2007 for Word, Excel, and PPT. 90% of what we test is for internal use, so we control the platform.

Given that approximately 5% of our rely on AT to perform their daily jobs it is absolutely critical that all electronic information resources that they use work with their assistive technology. Thus the strong emphasis on ensuring that everything works with our standard AT.

Mike Moore
(512) 424-4159

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of John Foliot
Sent: Tuesday, July 27, 2010 6:21 PM
To: 'WebAIM Discussion List'
Subject: [WebAIM] Testing with Screen Readers (was RE: Wai Aria how useful?)

Interesting thread, and some thoughts:

There is a real tension between building standards compliant sites that
work with all technologies versus 'testing' with one tool, and building in
hacks and other 'repair strategies' to support bad software. Just ask
those unfortunates who must still support IE6. If you really must test
with a screen reader, then test with more than one: you test with more
than one browser, right?

The other point that must be considered is that to really be able to
'test' with any screen-reader, you should be a daily screen-reader user.
The problem we have is developers who want to do the right thing, but are
not competent with using Adaptive Technology, so really, all they are
doing is listening to their site read aloud: they are often missing out on
much of the interactivity daily users apply to using their software. For
production class developers, they are often better served by asking (and
paying) daily AT users to do the testing for them, rather than pretending
that opening up NVDA, or the time-crippled JAWs eval copy (which is
illegal, but...) and listening to a site read aloud and calling it
"testing".

Finally, as a very real question, what exactly are you testing *for* when
using a screen reader? If a developer is testing to find holes, I would
suggest they are approaching the problem from the wrong angle: you should
be testing that solutions implemented work as desired. So the developer
should be thinking about the problems and solutions long before they get
to the functional testing stage, and there are plenty of developer tools
out there that can confirm if your code is moving in the right direction
(understanding how a DOM inspector works is crucial); achieving real
accessible content means making some decisions at the foundational stage -
it's architectural. Waiting for a walk-through using AT to find problems
is almost certainly a recipe for ensuring there will be problems to
find...


As always, IMHO

JF



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:webaim-forum-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of = EMAIL ADDRESS REMOVED =
> Sent: Tuesday, July 27, 2010 1:37 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Wai Aria how useful?
>
> 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
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED = [mailto:
> > = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir Rúnar
> Gunnarsson
> > Sent: Monday, July 26, 2010 5:21 PM
> > To: WebAIM Discussion List
> > Subject: Re: [WebAIM] Wai Aria how useful?
> >
> > 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.
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Birkir Rúnar Gunnarsson [mailto: = EMAIL ADDRESS REMOVED = ]
> > >> Sent: Thursday, July 22, 2010 6:43 PM
> > >> To: WebAIM Discussion List
> > >> Subject: Re: [WebAIM] Wai Aria how useful?
> > >>
> > >> 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
> > >>>>>
> > >>>>>
> > >>>>> -----Original Message-----
> > >>>>> From: = EMAIL ADDRESS REMOVED =
> > >>>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> > >>>>> = EMAIL ADDRESS REMOVED =
> > >>>>> Sent: Wednesday, July 21, 2010 2:13 PM
> > >>>>> To: WebAIM Discussion List
> > >>>>> Subject: Re: [WebAIM] Wai Aria how useful?
> > >>>>>
> > >>>>> 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
> > >>>>>