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

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

From: Gregory J. Rosmaita <unagi69@concentric.net>
Date: Thu, 16 Dec 1999 13:00:01 -0500
Message-Id: <4.1.19991216111535.00a50150@pop3.concentric.net>
To: Jon Gunderson <jongund@ux1.cso.uiuc.edu>, 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>
in response to my post, archived at:
Jon Gunderson wrote:

I agree table markup items should be higher priority in WCAG.  But I am not
sure what that has to do with the DOM.  Implementing and exposing the DOM
will allow assistive technologies to access table markup information
provided by the author.  If the author didn't include information on table
markup, the DOM cannot magically provide it to an assistive technology or
for that matter a graphical rendering in a GUI environment.  

I am therefore not sure what you mean by "pushing it off on to the DOM"?

aloha, jon!

as i repeatedly asserted at the Austin Face2Face meeting, i do NOT expect the
DOM or a user agent to fix a poorly marked up table, which is precisely why i
have asked that all of the markup relating to tables in HTML4 that was included
in the spec in order to provide structure and contextual slash semantic
information about logical relationships between different components of the
table, be accorded a P1...

the problem is two-fold:  first, authors must be encouraged, nudged, and, in
some cases, perhaps, even forced, to construct tables that (a) validate, (b)
incorporate all of the elements and attributes defined for tables that promote
structure; and (c) use all of the elements and attributes defined for tables
that convey semantic slash contextual information...  (which is why i have
cross-posted this to a number of dependent WAI working groups)

second, based upon the discussion and feedback from developers received at the
UA Face2Face in Austin, it is increasingly apparent that developers are loathe
to open the pandora's box that is table navigation...  while i still believe
that it is the user agent's responsibility to provide at least gross
navigational access to tabular information (i.e. provide a list of tables in a
document, a go=to listed table functionality, search within a table, traverse
column, traverse row, etc.), the way the UAGL is currently (or, rather, in the
absence of a post-F2F draft, soon-to-be) constructed, adaptive technologies
will have to provide non-graphical users not only with access to the content of
tables, but with the ability to search within tables and to navigate within
tables...  where is the most logical place for the assistive technology to
obtain the information necessary to provide the non-visual user with
orientation and mobility -- the 2 keys to non-visual navigation?  the DOM

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 upon

what we are currently drafting in the UA WG, isn't so much quote User Agent
Accessibility Guidelines unquote, but quote Rendering Agent Guidelines unquote,
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...

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 tables,
their structure, and the context of each component from UAs that do not (at
least not immediately) implement the DOM......

He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
Gregory J. Rosmaita <unagi69@concentric.net>
   WebMaster and Minister of Propaganda, VICUG NYC
Received on Thursday, 16 December 1999 12:55:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:28:22 UTC