Re: PROPOSAL: Assistive Technology Checkpoints in the Guidelines

I am gratified to read that there is a mechanism for total inclusion of
persons with disabilities being contemplated re the message below.  I
had been concerned that if we move on our current course that assistive
technologies would be playing to a proprietary standard on one platform
which although holding promise is slow in being adopted and does not
address all issues.  For instance, I have seen in the latest edition of
netscape for windows.9x that when a media presentation is addressed that
there is a nice keyboard interface for raising and lowering the volume,
moving through the content and stopping, playing and pausing.  This is
done with no interference to the a t and to my screen reader is totally
transparent.

I must point out one thing that we were told early on in our guideline
development by Chuck.  "Microsoft considers web content to be more than
documents rather they should be viewed as applications..." This bears
out the point below that at some point, there will be no distinction
between the gui and what it delivers.  We need to look at the entire ua
there fore just as if there was an electronic information display
standards organization and we were a sub part of a subpart of that
organization which deals with access issues and we were charged with
developing guidelines for the display tools themselves, we'd be
concerned with their controls as well as document rendering.  is not the
authoring tools group concerned with these issues as well?  Can we
coordinate with them on this?  Old habits die hard.  I am using double
spaces at the ends of logical sentences.  Please forgive me <g>? 

Underlying much of this discussion is that fact that no matter what we
do, much of the web could be inaccessible because of a lack of
conformance to some simple basic authoring hooks or because at least for
now there is simply no way to address a particular issue.
 
schwer@us.ibm.com wrote:
> 
> Charles,
> 
> >  2. DOM can only be considered as part of a solution for Desktop user
> agents
> >  for the following reasons:
> 
> While I agree that we DOM level 2 cannot address specific interface related
> to desktop components like menus, etc. I strongly disagree that it cannot
> in the future. It is important that assistive technology be able to access
> the chrome area as well as supporting browser dialogs so that we ensure
> that assistive technologies be able to access all web browser functionality
> in the future. While Windows may provide access to a great deal of these
> features through MSAA, other operating systems do not. We should not be
> preclude users from accessing browser functions as simple as changing the
> proxy server just because the operating system does not have an object
> model or even an offscreen model. In fact, for many systems this
> unacceptable depending on the device you are operating.
> 
> >
> >  a. DOM does not provide any information or the emulation of controls for
> >  the other parts of the user interface (i.e. controls, menus, staus
> lines,
> >  dialpg boxes).  This information needs to come from a non-DOM source.
> DOM
> >  will never provide information or control about these parts of the user
> >  interface.
> >
> 
> While this is true today, this should not be true in the future. I see no
> reason why we cannot create a DOM interface for system GUI components. The
> way the web is going it is going to be difficult to decide what is a GUI
> component and what is not. Requiring assistive technologies to get
> information from different non-DOM sources inhibits accessibility solutions
> from being created for each platform. For example, constructing an
> offscreen model to support a screen reader is a major effort. We should
> make an effort in future DOM releases, ensure that web browsers provide
> access to the whole browser and not just the client area.
> 
> >  b. DOM does not have a defined interoperable interface for use by
> external
> >  programs.  Some group members say this is not a major issue (including
> >  myself at times), but it is potentially a weak link if user agents
> running
> >  on the same plateform use different methods to expose DOM.  Assistive
> >  technology would then need to "know" where to look.  Also DOM does not
> have
> >  any conventions for more simultaneous access to the DOM.
> >  How would DOM resolve manipulation requests from both the user agent and
> >  the assistive technology?
> >  How would the user agent tell the AT that it changed something?
> >
> 
> One of my recommendations for DOM access is to ensure that access to the
> DOM be reentrant. In fact I am going to bring this issue up at the DOM
> working group tomorrow. This can be accomplished internally by semaphore
> protection to a shared library. Through a OM manager that services
> requests, etc.
> 
> A user agent would tell an AT that something changed by providing a
> listening mechanism. We did this when defining the Java Accessibility API.
> In this case, each object provided for property change notification to
> registered listeners. In the current object model terminology we would need
> to determine which nodes are designated as capture nodes for specific
> events so that we do not attach listeners to children that are not allowed
> to fire these event notifications.
> 
> >  c. The use of DOM would require Assistive Technolgy to sub class the
> user
> >  agent as a special technology and some assistive technology companies
> may
> >  find this requirement to restraining as the primary mechanism for
> >  accessibility, escpecially on MS-Windows plateforms that have
> accessibility
> >  models based on active accessibility.  Denis Anson made a good point.
> If
> >  push this type of technique, it means that user with disabilities will
> need
> >  to wait for AT developers to provide access to new implementations of
> DOM.
> >  More general techniques like active accessibility, offer improved
> >  timeliness to new releases of  user agents.
> 
> First, this is not true because users will use whatever mean they do today
> to access the information or continue to do without it. If we keep relying
> on reverse-engineered or solutions that only suit a particular platform,
> disabled users will continue to be left behind in favor of a short fix.
> 
> This issue needs to be reconsidered.
> 
> I will be at the DOM working group meeting for the next 2 days, but I would
> like the User Agent think hard on this.
> 
> 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 02/08/99 01:39:46 PM
> 
> To:   Jon Gunderson <jongund@staff.uiuc.edu>
> cc:   w3c-wai-ua@w3.org (bcc: Richard Schwerdtfeger/Austin/IBM)
> Subject:  Re: PROPOSAL: Assistive Technology Checkpoints in the Guidelines
> 
> As a preliminary comment, most of these things are covered under the
> general principle 'provide device-independent access to all functionality
> of the user agent' (which seems a lot like the current checkpoint 3.1.1)
> 
> The difference is that this proposal is splitting out particular functions
> and requiring them (of particular browsers, in the current incarnation).
> 
> The issue of whether to implement the w3c recommendation for DOM is
> separate.
> 
> Charles McCathieNevile
> 
> On Mon, 8 Feb 1999, Jon Gunderson wrote:
> 
>   Based on feedback from the group I think our current checkpoints related
> to
>   assistive technology compatibility need to be reconsidered for the
>   following reasons:
> 
>   1. The current techniques for comaptibility read more like techniques
> than
>   statements of assistive technology needs.
> 
>   2. DOM can only be considered as part of a solution for Desktop user
> agents
>   for the following reasons:
> 
>   a. DOM does not provide any information or the emulation of controls for
>   the other parts of the user interface (i.e. controls, menus, staus lines,
>   dialpg boxes).  This information needs to come from a non-DOM source.
> DOM
>   will never provide information or control about these parts of the user
>   interface.
> 
>   b. DOM does not have a defined interoperable interface for use by
> external
>   programs.  Some group members say this is not a major issue (including
>   myself at times), but it is potentially a weak link if user agents
> running
>   on the same plateform use different methods to expose DOM.  Assistive
>   technology would then need to "know" where to look.  Also DOM does not
> have
>   any conventions for more simultaneous access to the DOM.
>   How would DOM resolve manipulation requests from both the user agent and
>   the assistive technology?
>   How would the user agent tell the AT that it changed something?
> 
>   c. The use of DOM would require Assistive Technolgy to sub class the user
>   agent as a special technology and some assistive technology companies may
>   find this requirement to restraining as the primary mechanism for
>   accessibility, escpecially on MS-Windows plateforms that have
> accessibility
>   models based on active accessibility.  Denis Anson made a good point.  If
>   push this type of technique, it means that user with disabilities will
> need
>   to wait for AT developers to provide access to new implementations of
> DOM.
>   More general techniques like active accessibility, offer improved
>   timeliness to new releases of  user agents.
> 
>   So I would like to suggest five checkpoints for people to think about,
>   criticize, modify and/or comment:
> 
>   ** The following checkpoints ae based on the assistive technologies point
>   of view **
> 
>   Checkpoint 6.2.1 [Priority 1} Allow assistive technology to access
>   information about the current user interface controls (windows, menus,
>   toolbars, status bars, dialog boxes).
> 
>   Primary techniques: Accessibility APIs or use of operating system
> standard
>   controls.
> 
>   Checkpoint 6.2.2 [Priority 1} Allow assistive technology to simulate the
>   selection and activation of user interface and document controls
> (windows,
>   menus, toolbars, status bars, dialog boxes).
> 
>   Primary techniques: Accessibility APIs or use of operating system
> standard
>   controls.
> 
>   Checkpoint 6.2.3 [Priority 1] Allow assistive technologies to access
>   information about the current information being rendered by the user
> agent.
> 
>   Primary techniques: Accessibility APIs that provide information on
> document
>   rendering and/or DOM.
> 
>   Checkpoint 6.2.4 [Priority 1] Allow accessibility features (accessibility
>   flags and interfaces. ) of the operating system to provide alternative
>   rendering information and user interfaces for the user agent.
> 
>   Checkpoint 6.2.5 [Priority 2] Allow assistive technology to change the
>   rendering of document information on the user agent.
> 
>   Rationale: In some cases it maybe useful for the assistive technology to
>   change the rendering of a document.  For example for a person with
> certain
>   types of visual learning disabilities it maybe important to simplify the
>   rendering of the document and allow the person to use the mouse to point
> at
>   objects and have the contents of the object spoken to them.   It could
> also
>   be used for table linearization if the assistive technology felt that was
>   the best way for them to provide access to table information.
> 
>   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
> 
> --Charles McCathieNevile            mailto:charles@w3.org
> phone: +1 617 258 0992   http://purl.oclc.org/net/charles
> W3C Web Accessibility Initiative    http://www.w3.org/WAI
> MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

-- 
Hands-On Technolog(eye)s
Touching The Internet
ftp://ftp.clark.net/pub/poehlman
http://poehlman.clark.net
email: poehlman@clark.net
voice 301-949-7599
Dynamic Solutions Inc.
Best of Service for your small business network needs
http://www.dnsolutions.com

Received on Tuesday, 9 February 1999 08:51:15 UTC