Issues

After reviewing the documents Jon referenced, I believe that there are some
issues we need to consider based on an action item I am working on with
Mark Novak for the PF group:

   We have to be careful of what we put in the DOM and do not put in the
   DOM. What I feel is needed is an interface that extends the DOM for a
   user agent. This way we can preserve the existing DOM for some of its
   intended purposes such as servlet processing of HTML pages where user
   interface issues are not of consideration.
   We need to create an AccessibleObjectModel which extends the DOM to
   application components. The DOM provides some key features that we can
   reuse namely an architected event model, a range model, an iterator, CSS
   to node mapping, and a tree structure.
   The new AccessibleObjectModel needs to be designed such that each
   document node can be constructed by a mapping of XML semantic schemas
   into each individual node.
   Position information is not important for all assistive technologies if
   we can provide accessible action sets for specific node types as
   specified by its schema. Screen reader technology may be interested in
   position information when it needs to determine where line breaks in
   text occur or if they need to map objects to an OSM representation. The
   need for mapping to an OSM representation should be less important with
   true object model technology. Position information is very relevant to
   screen magnifiers that will use the caret or selector position to pan
   the magnification point to the users point of focus. Position
   information should not be stored in the core DOM because there it has no
   meaning in a non-visual orientation. This again is why we need to create
   a new AccessibleObjectModel that inherits from the DOM to provide this
   feature.
   Keyboard bindings could be specified for specify node types based on the
   schema. Although it would be up to the authoring tool and/or browser to
   define these, we will need to establish a set of key binding for
   specific node types that will not conflict with different operating
   system specific key bindings for obvious reasons. This is something we
   had to deal with for Java.
   On the issue of using standard rather than custom controls when
   designing user agents, the accessible object model should define an
   interface that can be applied to application object model components.
   The interface will provide the necessary information to access a
   particular object model component based on the specified XML schema. On
   some systems like UNIX with the X Windows System, these components may
   be part of someone's widget set. Allowing the browser (one user agent
   example) to map the proper semantic information to that component or
   node allows the user agent to use whatever widget set they like and
   still be accessible. Bottom line: The restriction to use standard
   controls is an unnecessary restriction if we design the Accessibility
   interface properly.
   Regarding the issue of "Allowing the user to turn on and off support for
   spawned windows" We need to develop and AccessibleApplication interface
   that can be implemented by a user agent so that an assistive technology
   can be notified when a spawned document has focus. This is again
   separate from the DOM.


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

Received on Monday, 29 March 1999 18:03:36 UTC