Re: Issues

Rich, by this do you mean the interface provided to the DOM should be an
extended one, which also includes platform-specific information (keyboard
bindings, volume controls, etc etc?

Charles

On Sat, 3 Apr 1999 schwer@us.ibm.com wrote:
  
  >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?
  
  The object model that extends the DOM should contain UI component
  informaiton such as keyboard bindings, etc. This would include position
  information. I agree with CMN that position information does not belong int
  he 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
  
  
  
  Charles McCathieNevile <charles@w3.org> on 04/02/99 01:24:30 PM
  
  To:   mark novak <menovak@facstaff.wisc.edu>
  cc:   Richard Schwerdtfeger/Austin/IBM, w3c-wai-ua@w3.org
  Subject:  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
  
  
  
  
  
  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Saturday, 3 April 1999 20:31:58 UTC