- From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
- Date: Fri, 17 Dec 1999 10:16:06 -0600
- 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 upon >Netscape... 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 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... 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 document. > >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...... 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