Re: DOM Issues

I just want to remind the participants of today UA telecon that we want to
focus on what can be put in the current UA guidelines.  I want to support
the efforts of the PF group in guiding future technologies to be more
accessible, but want to keep our feet on the ground for the current UA
guidelines.

I think by having general checkpoints that state the access problem and a
dynamic techniques document we can have a living document that can
incorporate new features as they are define.  

The goal of todays meeting is resolving what the those checkpoints are and
what the techniques document can say to help developers right now.

Jon


At 06:35 PM 3/29/99 -0500, 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.
>
>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.).
>
>
>>   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.
>
>If individual nodes maps to individual elements (??), then we may also need
>a grouping and un-grouping semantic mapping as well.
>
>
>>   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.
>
>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.
>
>
>>   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
> 
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 Wednesday, 31 March 1999 10:03:04 UTC