Re: Issues

Rich's email marked RS:, Mark's thoughts MN: mine CMcCN:

On Mon, 29 Mar 1999, mark novak wrote:

  just wanted to add a few thoughts....
  
  At 6:01 PM -0500 3/29/99, schwer@us.ibm.com wrote:
  >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.
MN:  
  The things Rich is referring to here, are proposed in DOM Level 2.  I'd prefer
  to not call this new object model anything using the word "accessible", since
  I believe the potential scope is much larger (e.g., automated testing tools,
  validation tools, search engines, etc.).
CMcCN:
I agree with Mark here.
  
RS:  
  >   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.
MN:  
  If individual nodes maps to individual elements (??), then we may also need
  a grouping and un-grouping semantic mapping as well.
CMcCN:
It would be helpful to have a method for selecting a range, across element
boundaries. I believe this is provided by DOM 2.  
RS:  
  >   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.
CMN:
Position information is only relevant to a particular architecture which
is intrinsically visual. Within that architecture it is important, as Rich
explains, but I am not sure that it is of particular relevance to the DOM,
which should not presuppose a particular rendering architecture.  
RS:  
  >   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.
MN:  
  I think these would also be in the ??? object model that extends DOM,
  not DOM itself?
  
  
  >   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.
CMcCN:
If the standard control mechanism for a system is to provide a particular
API (as with accessible Java) then the requirement has been met to a large
degree. (there is still the issue of consistency, but that is usability
rather than being inaccessible to assistive technology.)  
RS:  
  >   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 Friday, 2 April 1999 14:27:43 UTC