WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Reading tables in JAWS

for

From: Lucy Greco
Date: Feb 4, 2014 10:35PM

Hello:
Nicely said. I would echo you on one point. The deficiency is not only
in the AT but in the training given to at users I regrettably know of
to many at users that don't know that there are ways to navigate a table
besides just using the down aero to read line by line. If you don't use
table nav commands using left and write only move letter by letter so
telling someone to navigate a table with arrows only just does not work. I
would say in my 9 years of working with college students of the top
caliber of the ones that come to Berkley, only 1 in 10 new how to read
tables at all. many of my students did not even know why there screen
reader even bothered to tell them about tables.
I would teach them how to use table commands and they would always rely
on them from that point on. they all came back and said I can do so much
more now that I know that .

Unfortunately I feel that a majority of people training AT least in
California really don't have a clue about how to really use a screen
reader let alone train someone to the point where they can become
proficient. I know that seems harsh but I have run in to so many trainers
that don't even look at the new features list when the screen reader
updates or the training tools the venders build in to say any of them are
any good at their jobs.


Jaws and NVDA both do a very good job on tables but how many people use
the feature is limited to how many people get taught how to use it. window
eyes the last time I tried to use it on a table just failed miserably.
At that point in time over 3 years ago now, windoweyes 7.0 if a table had
an imbedded form and yes it was appropriate the user would fill out the
form in table mode and as soon as they left table mode the form entry's
would be cleared away. Needless to say I stopped supporting windoeyes at
that time and focused on jaws and NVDA. I do think the way voice over
treats tables is good but I hate the concept of interacting and not
interacting that voiceover uses at the best of times. smile I fear the
change in the screen reader market is not for the good of access because
more people will start using windoeyes now so we need to find ways to
support them even if the screen reader market has better free choices.
Sorry for the long rant Lucy

Lucia Greco
Web Access Analyst
IST-Campus Technology Services
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu Http://accessaces.com
Follow me on twitter @accessaces


-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Birkir R.
Gunnarsson
Sent: Tuesday, February 04, 2014 7:02 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Reading tables in JAWS

We must remember that the assistive technology software and the end user
is as much a part of accessibility as the webpage authors.
It is up to the assistive technology that targets a certain population to
use technical advances and user testing to find ways to make all manner of
information, including complex tables, intuitive for that user population.
It is up to the end user and the system around the end user to make sure
he or she receives sufficient training to use that assistive technology to
pick up information, which is the ultimate purpose of accessibility.
If we do not go by this model, we might as well not bother to mark up data
tables correctly, since no end users understand them anyway.
The alternative would be to expect the webpage or content developer invent
some sort of a workaround that they think would better communicate the
information to users with disability x using assistive technology
application y.
This is an impossible task. After all users with disabilities
understandably do not want to self identify on the web, so creating
content optimized for certain groups of users with assistive technologies
is impossible.

All we can expect the webpage developers to do is to mark up the content
in a standard manner that communicates all the relevant information and
relations of page components to each other to the assistive technologies.
If users are not taking advantage of accessible markup, it means that more
attention must be given to sufficient training and more consistent
assistive technology support.
I have always felt that sadly this segment of accessibility has often not
received the attention that it deserves.

In a survey that me and my colleague carried out last year, involving
450 screen reader users, over 70% of them claimed to navigate tables using
table navigation commands.
Of course the survey is biased in that only users with the skills to take
an online survey, and the interest to do so, were involved.
Also we cannot verify precisely what they mean by "table navigation keys".

I hope that the advent of the touchscreen interface, with possibilities of
raising certain areas of the screen to form a tactile pattern is the next
step in the evolution of accessible interfaces, one which may help give
better context and spatial understanding for users who are blind.
Fortunately we live in exciting times when it comes to technology.
All that being said, it is important to make tables accessible to the
extent possible, using standard html and accessibility techniques, and
rely on assistive technologies to interpret them and end users to
understand how to extract the information from them.
Optimizing information for a given assistive technology should only be the
case in extremely rare and specialized circumstances.
Cheers
-B
Birkir Gunnarsson
Senior Accessibility Consultant | Deque Systems



On 2/4/14, Bryan Garaventa < <EMAIL REMOVED> > wrote:
> It depends on the type of content and the interaction model.
>
> For example, the following table is an interactive ARIA Data Grid
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Data%20Grids/ARIA%20Data
> %20Grid%20(Dynamic)/demo.htm and is designed to have one tab stop and
> to allow screen reader access using
>
> the arrow keys.
>
> However, the most basic types of table, as seen at
> http://www.freedomscientific.com/Training/Surfs-up/Tables.htm
> require the use of the Virtual Cursor to navigate them effectively.
>
> Standard table navigation commands have existed for many years now, so
> it really comes down to whether or not the AT user has had
> introductory training on this type of screen reader functionality.
>
>
>
>
> ----- Original Message -----
> From: "Olaf Drümmer" < <EMAIL REMOVED> >
> To: "WebAIM Discussion List" < <EMAIL REMOVED> >
> Sent: Tuesday, February 04, 2014 3:09 PM
> Subject: Re: [WebAIM] Reading tables in JAWS
>
>
>> On 4 Feb 2014, at 23:59, Don Mauck < <EMAIL REMOVED> > wrote:
>>
>>> Anyone that just uses the arrow keys or the tab keys will never be
>>> able to successfully use and navigate tables using a screen reader.
>>
>> why is that? Aren't arrow keys a good default method to walk through
>> a table?
>>
>> It would be a matter of setting user preferences to control how much
>> accompanying information - on top of the cell's content - would be
>> presented (like type of cell, applicable header cells, etc.)
>>
>> Olaf
>>
>> >> >> list messages to <EMAIL REMOVED>
>
> > > list messages to <EMAIL REMOVED>
>


--
Work hard. Have fun. Make history.
messages to <EMAIL REMOVED>