- From: <schwer@us.ibm.com>
- Date: Fri, 3 Dec 1999 17:03:49 -0600
- To: lauren@sqwest.bc.ca
- cc: "Gregory J. Rosmaita" <unagi69@concentric.net>, User Agent Guidelines Emailing List <w3c-wai-ua@w3.org>
I agree whole heartedly. To me the DOM is the basis for being an industry standard cross-platform mechanism to access not only document content but also the chrome that encompasses documents comprising an application. Just to take some MSAA/Java accessibility features that are in DOM 2: - events and the ability to monitor them on a component or "element" basis - attributes and the ability to get at them (role information, etc.) - application/document tree navigation mechansims (AccessibleChildren Java , child information in MSAA). DOM provides tree navigation - Text elements and their attributes - Element Activation mechanism (links) Assuming an appropriate schema we should be able to semantically map an XML document into a DOM with the appropriate accessibility information I am not saying that all we need for accessibility is in the DOM today but the combination of future extensions to the DOM and other W3C based accessibility solutions we have mechanisms for open accessibility standards that can apply to a variety of devices and solutions. Another point to note is that differentiation between the concept of what constitutes an application and a document is becoming muddled. For example, JavaScript adds many application features to a document although it provides no semantic information as of yet. Also, web sites are directly tied to servlets which generate dynamic content constituting an "application." This is why I feel so strongly about the DOM when discussing accessibility and how its simplicity can help the accessibility of pervasive device accessibility in the future. It would be nice if we could look at using the DOM for other non Web-based user agent applications as well at least for the document area. 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 "Lauren Wood" <lauren@sqwest.bc.ca> on 12/03/99 01:58:16 PM Please respond to lauren@sqwest.bc.ca To: "Gregory J. Rosmaita" <unagi69@concentric.net> cc: User Agent Guidelines Emailing List <w3c-wai-ua@w3.org> Subject: Re: WD-WAI-USERAGENT-19991105 review On 3 Dec 99, at 14:46, Gregory J. Rosmaita wrote: > aloha, charles! > > you raise a very valid question -- do assistive technologies need to use the > write functionalities of the DOM in order to provide access to content, but the > working group has -- so far -- heard extremely little from ANY of the adaptive > technology vendors whose opinions we've solicited, and whose representatives > have sat amongst us, detailing exactly what it is that they need from the > DOM... this is input that needs not only to be plowed back into the UA WG, but > the DOM WG as well... One of my reasons for doing the DOM in the frst place was to give adaptive technology vendors a standard interface so they could write tools that hook into browser, editors, etc which implement the DOM. So I think such tools should implement the DOM, to enable this. There is, to my mind, little point in implementing a proprietary interface when a standard one is available, particularly since the WAI groups have input to the standard interface and not to proprietary interfaces in general. If adaptive technology vendors (screen readers, etc) implement hooks to be a client of the DOM, they should be able to hook into any DOM implementation with minimal changes. Otherwise they need to change their client interface for each tool. For example, SoftQuad Software's HoTMetaL and XMetaL implement the DOM (more with each release) and Mozilla implements the DOM, and MSIE implements the DOM, and .... so why reinvent the wheel each time? If these tools can't use the DOM for some reason, then the DOM WG needs to know about this. Lauren
Received on Sunday, 5 December 1999 12:29:06 UTC