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

Re: WCAG Priority Levels for accessibility-oriented TABLE eements and attributes

From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
Date: Fri, 17 Dec 1999 10:16:06 -0600
Message-Id: <4.1.19991217094957.00aeff00@staff.uiuc.edu>
To: "Gregory J. Rosmaita" <unagi69@concentric.net>, Ian Jacobs <ij@w3.org>
Cc: User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>, Web Content Accessiblity Guidelines Mailing List <w3c-wai-gl@w3.org>, Authoring Tools Guidelines List <w3c-wai-au@w3.org>
JG in response to GR:
>i am also very concerned that the emphasis on the DOM leaves non-visual users
>in the lurch -- until the DOM is realized and uniformly implemented, how are
>assistive technology vendors to provide the navigational and orientational
>information necessary to provide users with the ability to traverse and query
>tabularized data to obtain contextual and semantic information, let alone
>navigate them effectively and efficiently?  yes, i know that JFW uses the MSIE
>DOM to provide superb access to content, but does that help the JFW user who
>works in a single browser intranet, where the single browser is not IE?  yes,
>HPR provides exemplary access to tabular data, but it is utterly dependent

JG: The working group tried for over a year to deal with the table issue,
including linearization techniques and complex visual transations.  I main
problems we kept coming back up is:

1. Assistive technologies use different techniques to access visual
renderings of information

2. Visual renderings were incomplete representations of the information the
author provided in the source document, so AT using visual rendering would
always be missing information

3. Visual renderings do not carry any information about the relationships
between cells rendered in a table or in many cases the boundaries in cells.
 ATs maybe able to guess these boundaries, but it seems like a waste of
effort if they could use the information in the DOM.

4. The idea of point-of-regaurd and focus were different for visual and
auditory renderings.  Things that make sense in one medium, did not make
sense in another.

5. Specialized navigation mechanisms (with I assume some type of point
point of reguard indicator moving with the navigation) that don't make
sense in one rendering medium, would complicate an already problematic
keyboard access issues.  It would also potentially delay implementation by
mainstream browser developers as they try to figure our how they fit into
their existing technologies.

6. It was felt that emphesis should be placed in the guidelines on what
will work in the long term.  If the guidelines talk about alot of
techniques that don't make sense for visual rendering, some companies may
evenntually implement them, but they won't happen for a long time.  This
would drain resources from long term solutions and give the impression to
AT developers that they do not have to address their technology.

>what we are currently drafting in the UA WG, isn't so much quote User Agent
>Accessibility Guidelines unquote, but quote Rendering Agent Guidelines
>as the over-riding emphasis on the DOM will lead to the extinction of the user
>agent slash browser as we currently know it, leaving the interpretation of
>document source to parsers and rendering agents...  and, while that is a
>commendable ideal, i and countless others are still left in the lurch, without
>reliable, robust, cross-platform, and non-browser or AT-specific means of
>navigating tables or querying them for any contextual slash semantic
>information they may contain...

JG: The DOM provided the only mechanism that the group could find consensus
on that accurately represented the document.  The group decided that access
to the DOM and implementation of the DOM was the path that would lead to
improved access by assistive technology in the shortest time and with the
best results for consumers.  Some companies like Henter-Joyce are already
using this model, and others are not.  It is the groups responsibility to
work with AT developers and to help them understand how to use the DOM.  It
is also important to work with mainstram browser developers to fully
implement the DOM and develop and document high speed access to the DOM.
This will be an issue during the candidate recommendation stage of the

>i would, therefore, also strongly advocate that -- at least in regards tables
>-- that the UAGL use a bit of if-then logic: "for UAs which implement the DOM"
>and "for UAs which do not implement the DOM" -- in according priority to table
>navigation, so that assistive technologies can obtain information about
>their structure, and the context of each component from UAs that do not (at
>least not immediately) implement the DOM......

JG: We have tried to do this in the past and the group could not find
checkpoints or techniqes that the group could come to consensus to be
technically sound as long term solutions.  It always came back to the DOM
as the only medium that seemed to make sense.

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua
Received on Friday, 17 December 1999 11:18:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:24 UTC