Re: Tenative meeting on the DOM with AT vendors for the User Agent Guidelines

With structured information such as HTML and XML markup (even when it is done
badly there is structure to the information) it is indeed useful to have
access to all the available structure semat=ntics and the content. I agree -
building an Off Screen Model relies on the content being presented, which may
or may not be the case. The choice then seems to be whether we require of
user agents a way to present all the semantic information (i.e. element types
and their attributes) on screen, or to expose it through an API, or to do at
least one of these.

Following the discussion, it seems that having the information exposed
through an API is generally a superior choice, and the DOM is the natural
choice for documents, although a case could be made for the use of a
platform-specific alternative where one is available - for example the Java
access bridge or Microsoft Active Accessibility.

One thing that does not seem (as I understand the discussion) to follow is a
requiremnt to completely implement the DOM, which provides for manipulation
of the document as well as "read access" to it. Indeed, it could be argued
that doing this makes the browser liable to being an authoring tool, opening
a whole new bag of tricks for accessibility.

(I don't have the answer to this question either. But it seems to be getting
clearer slowly)

Charles McCN

On Mon, 31 Jan 2000, Peter Korn wrote:

  Hi Charles,
  
  Please pardon my soap-box...

CMN: On the contrary, thank you for spending long enough atop it to bring
some clarity to bear.
PK:  
  There is a significant issue with the OSM approach: responsibility for
  problems in accessibility are almost never clear.  If one screen reader's OSM
  is able to capture information on the screen through some particularly tricky
  heuristics, then it is to the benefit of the users of that particular screen
  reader, but it may not work in other screen readers (to the detriment of those
  users).  Then the question becomes who should change -> the poorly behaved
  application putting that information on the screen, or the OSMs of the other
  screen readers?
  
  If there is a standard way for applications to describe their contents via a
  programming interface (API), then it is much eaiser to figure out what is
  going wrong and fix it.  The API may be insufficiently expressive, the app may
  not be implementing the API properly, or the assistive technology may not be
  utilizing the API.  Those three things I claim are eaiser to test and verify
  than the finger-pointing we get via the OSM model.  When we have an API,
  assistive technologies can always go beyond the API (as happens already
  today), if the API or the application implementation(s) of the API do not meet
  their needs.
CMN had written  
  > I think a DOM which includes access to the chrome is a great benefit to
  > accessibility, and using itis a very good way to meet the needs of
  > users. However I am not sure that it is always a requirement. 
and PK responded:  
  Should we not require full keyboard access?  After all, the functionality of
  one screen reader - outSPOKEN for Macintosh - provides features like Find that
  make keyboard access less critical (especially since on the Macintosh there
  isn't that much support in the OS for keyboard access to controls).  Also, an
  assistive technology could potentially assign their own keyboard access
  mechanism on top of ill-behaved apps (just as screen readers build information
  in their OSMs that by rights should be directly exposed by applications).
  
  
  I think going forward we need to require that applications provide *all* of
  their semantic information directly via a clear and easy to use API to
  assistive technologies.  Assistive technologies have a long, proud, and
  painful history hacking around operating systems and applications so as to
  provide their users with access.  The engineering staffs of these companies
  have tremendous expertise in reverse engineering behavior, and these
  techniques have provided tens of thousands of users with workable access
  solutions and thereby employment and general access to information.  But it is
  time we stop relying on this expertise, and leaving users with a mish-mash
  patchwork of access quality to applications that are supposedly complying with
  a new set of guidelines on how to be compatible with assistive technologies. 
  We can do better than that, and require better than that, of the next
  generation of applications.
  
  
  Peter Korn
  Sun Accessibility team
  

--
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
21 Mitchell Street, Footscray, VIC 3011,  Australia

Received on Tuesday, 1 February 2000 04:28:50 UTC