RE: RESOLUTION: Table access checkpoints for Desktop Graphical User Agents

I think most AT vendors would only need to read the DOM for alternative
rendering.  I think it would be a mistake for the guidelines to imply,
suggestion or advocate the manipulation of the DOM to get sometype of
visual rendering that is useful for reading information from the graphical
rendering of the document.   DOM manipulation would only be approapriate as
an interim or short term solution until the AT could integrate the full
model into their application.  

Jon


At 02:53 PM 1/28/99 -0800, Charles Oppermann wrote:
><<
>I am concerned that systems don't support an exposed DOM. The purpose of the
>DOM is to provide a cross-platform template which can enable assistive
>technologies to quickly provide access to different browsers our document
>presentation tools. 
>>>
>
>Actually, the goal of the DOM specification is to define a programmatic
>interface for XML and HTML.    I don't believe it addresses the needs of
>external clients or assitive technology.  A known limitation of DOM level 1
>is access control and it doesn't appear to be addressed yet in DOM level 2.
>
><<
>Full support for an accessible DOM interface would make it easier for
>products like the IBM Home Page Reader to rapidly build support for various
>web browsers/ document viewers on a broad host of applications, machines,
>and environments.
>>>
>
>DOM is perfect for things like Home Page Reader!  If Home Page Reader was
>implemented using the Internet Explorer Web Browser control, it would have
>complete access to the Dynamic HTML object model and could play with it all
>it wanted to (with the associated risks of breaking scripts).
>
>I believe that this is what CAST and The Productivity Works are doing with
>their products.
>
>The problem is getting access and manipulating someone else's DOM.
>Accessing an object model out of the address space of an existing browser
>presents performance, reliability and security concerns that have not yet
>been addressed.
>
>For example, if I hack on the object model of a page downloaded from the web
>and convert all the table objects to something else, the script provided by
>the author of the page may break when it expects to access a table object
>and find none.
>
>I think providing the HTML object model in a read-only fashion is a great
>idea - but it just hasn't been addressed yet.
>
>
>-----Original Message-----
>From: schwer@us.ibm.com [mailto:schwer@us.ibm.com]
>Sent: Thursday, January 28, 1999 9:23 AM
>To: Charles Oppermann
>Cc: Jon Gunderson; w3c-wai-ua@w3.org
>Subject: RE: RESOLUTION: Table access checkpoints for Desktop Graphical
>User Agents
>
>
>
>
>
>Chuck,
>
>I am concerned that systems don't support an exposed DOM. The purpose of
>the DOM is to provide a cross-platform template which can enable assistive
>technologies to quickly provide access to different browsers our document
>presentation tools. While I applaud all the work Microsoft has done on MSAA
>I would strongly advocate the track taken by the W3C which requires a
>platform independent DOM specification and apply accessibility requirements
>to it.
>
>There will be cases where hand held devices will not provide MSAA and
>standard needs to be followed to quickly provide access to that document.
>
>We cannot achieve direct accessibility if we do not adhere to
>cross-platform standards.
>
>Full support for an accessible DOM interface would make it easier for
>products like the IBM Home Page Reader to rapidly build support for various
>web browsers/ document viewers on a broad host of applications, machines,
>and environments.
>
>I will admit that the DOM interface needs some work to support
>accessibility and my team is looking those issues. One example is a
>requirement that the DOM implementation to be re-entrant to allow assistive
>technologies to access the DOM without the fear of creating deadlock
>situations. I have not yet found this in the DOM specification, although it
>may be there.
>
>Rich
>
>
>
>Rich Schwerdtfeger
>Lead Architect, IBM Special Needs Systems
>EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm
>
>"Two roads diverged in a wood, and I -
>I took the one less traveled by, and that has made all the difference.",
>Frost
>
>
>
>Charles Oppermann <chuckop@microsoft.com> on 01/27/99 06:36:21 PM
>
>To:   Jon Gunderson <jongund@staff.uiuc.edu>, w3c-wai-ua@w3.org
>cc:    (bcc: Richard Schwerdtfeger/Austin/IBM)
>Subject:  RE: RESOLUTION: Table access checkpoints for Desktop Graphical
>          User Agents
>
>
>
>
>
>FYI - I'm evaluating the feasibility of making the DOM (or more
>specifically, Microsoft Dynamic HTML Object Model) a public interface.
>
>As I said in the previous teleconference, current methods of accessing the
>internal object model are unsupported.
>
>I'm worried about this proposal since it would
>(a) force browser manufactures to follow DOM
>(b) force browser manufactures to expose DOM directly.  Currently Internet
>Explorer supports Active Accessibility, which provides some DOM-like
>information, tailored to the needs or accessibility aids.
>
>As soon I have more information, I'll pass it on.
>
>Charles Oppermann
>Program Manager, Accessibility and Disabilities Group, Microsoft
>Corporation
>mailto:chuckop@microsoft.com  http://www.microsoft.com/enable/
>"A computer on every desk and in every home, usable by everyone!"
>
>-----Original Message-----
>From: Jon Gunderson [mailto:jongund@staff.uiuc.edu]
>Sent: Wednesday, January 27, 1999 3:12 PM
>To: w3c-wai-ua@w3.org
>Subject: RESOLUTION: Table access checkpoints for Desktop Graphical User
>Agents
>
>
>Tables Issue Resolution for Desktop Graphical User Agents
>The solution strategy for Desktop Graphical User Agents for making tables
>more
>accessible is for user agents to implement the Document Object Model (DOM)
>and
>provide an interface for assistive technology to access DOM.  Assistive
>technology therefore would have direct access to table information for
>alternaive rendering in speech, Braille or enlarged text.
>
>Advantages to DOM approach
>1. Assistive technology has direct access to element information and is not
>dependent on any filtering of information that occurs during graphical
>rendering of information.
>2. W3C recommendations exist for specifying implementation and conformance
>
>Potential Disadvantage of DOM approach
>1. Technique needs to gain acceptance by assistive technology developers.
>So
>far this has not been a problem since Henter-Joyce, Productivity Works and
>Alva
>participants are either already using DOM or are interested in its
>capabilities.
>
>Primary checkpoints for Desktop Graphical User Agents to implement
>1. Implement DOM level 1
>2. Expose DOM level 1 to assistive technologies
>
>Checkpoint under consideration and refinement
>1. Provide a means for the user to add accessibility functionality or
>change
>the rendering of a document using the scripting capabilities of the user
>agent
>
>Issues related to this checkpoint
>1. Intent is provide some way for user to adjust rendering or add
>functionality
>for legacy assistive technology by using scripting tools already available
>in
>many desktop graphical user agent technologies.
>2. This is not a good checkpoint since it is too specific, but could be a
>technique for a more general checkpoint.
>3. This may be a good checkpoint if it was more general, but if it was more
>general it could probably be defined as an asssitive technology.  It
>therefore
>would not need to exist.
>4. There is a DOM2 working group defining user side scripting capability,
>need
>to coordinate with that group and see how this issue relates to the work of
>that group.
>
>Checkpoints related to native table linearization by desktop graphical user
>agents have been rejected based on the following information.
>
>Potetential Advantage of Linearization Approach
>1. Current screen reader users would have somewhat better access to table
>information, but it is not a complete solution.  Users would still need to
>wait
>for it to be implemented before they could benefit from the feature.
>
>Problems with linearization approach
>1. Linearization is only one of many techniques in solving the table access
>problem, it doesn't meet the requirement for checkpoints stating a general
>user
>problem. It could be included as a technique in the technique document.
>2. It doesn't provide a path for innovation in solving table access issues
>and
>will become outdated as technology improves.
>3. Navigation and rendering are needed for a complete solution, which
>complicates the desktop graphical browser issue.
>4. None of the assistive technology vendors currently involved in the group
>have requested the inclusion of this feature.  Their interest seems to be
>more
>in the area of DOM or accessibility APIs for access to tables.
>5. Mainstream browser developers have indicated that this feature is
>technically difficult to implement.  It would take a long time for user
>agent
>developers to implement and therefore maybe obsolete before users would be
>able
>to benefit from the technique.
>
>If you have additional information that would change or extend this
>resoution
>please send it to the list as soon as possible for consideration by the
>group.
>
>Jon
>Chair UA working group
>
>
>
>
>
>
>Jon Gunderson, Ph.D., ATP
>Coordinator of Assistive Communication and Information Technology
>Division of Rehabilitation - Education Services
>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
>     http://www.als.uiuc.edu/InfoTechAccess
> 
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
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
	http://www.als.uiuc.edu/InfoTechAccess

Received on Friday, 29 January 1999 09:42:43 UTC