Re: Issues

>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

Received on Saturday, 3 April 1999 12:57:24 UTC