W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2010

RE: Using ARIA to control screen readers

From: Jonathan Avila <jon.avila@ssbbartgroup.com>
Date: Thu, 11 Nov 2010 20:51:52 -0500
Message-ID: <60c2247a47ce9a428220bc526edb8543@mail.gmail.com>
To: w3c-wai-ig@w3.org
Lucica wrote:

ō  As long as the user doesn't press any key the AT reads the entire list.
When D is pressed the description is alive and the AT reads it. Then what
happens? Does it move to element 3 being the next one in the markup? Does it
wait for the user's intervention because it cannot move on?



Do most screen reader users really just listen to the whole page?  Thatís
not how I would review the page.  I would prefer to use commands to move to
and announce chunks of information.  For example, I prefer to the next
paragraph navigation command but something like move to next heading and
speak the content below it would be optimal in many situations not reading
the entire page.



One solution is to create some hotkeys that the user could press to navigate
through the page and use aria to control speaking.  Since you are watching
the page hot keys to announce the page content you would know what element
the user is on and if the letter d hot key was pressed you could then speak
the description.  So essentially you would need two sets of hotkeys, one for
navigation to items and one for descriptions.  This sound similar to the
Firefox extensions that use XPath to allow users to create hotkeys to move
to relevant results within a page.  Those work through a plug-in, however
with ARIA this could work directly on the page.  This would however require
the user to learn some keystrokes for this site.  In addition, some screen
reader like JAWS would not pass the single letter keystrokes through to the
web application.



Best Regards,



Jonathan
Received on Friday, 12 November 2010 01:52:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:35 GMT