- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Thu, 14 Mar 2002 09:58:32 -0600
- To: aaronl@netscape.com (Aaron Leventhal)
- Cc: "Ian B. Jacobs" <ij@w3.org>, w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org
I believe this is essential. When you are dealing with simple objects like buttons or menus that really change infrequently, and which provide little data, there is less reason to go back to the well to get informaiton. In contrast if you were to have a spreadsheet with embedded objects or dynamic web content that can change frequently or which can contain large amounts of data then accessing it out of process is inadaquate to do the job. Rich Rich Schwerdtfeger Senior Technical Staff Member IBM Accessibility Center Research Division EMail/web: schwer@us.ibm.com "Two roads diverged in a wood, and I - I took the one less traveled by, and that has made all the difference.", Frost aaronl@netscape.c om (Aaron To: Richard Schwerdtfeger/Austin/IBM@IBMUS Leventhal) cc: "Ian B. Jacobs" <ij@w3.org>, w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org Sent by: Subject: Re: Issues and comments arising from UA evaluations w3c-wai-ua-reques t@w3.org 03/13/2002 06:23 PM To what extent do people think in-process DOM access is useful to AT vendors? Aaron Richard Schwerdtfeger wrote: Aaron, I think the concept of a DOM is clear to people doing actual web browser or server-based document development such as XML transcoding work. In this arena they use the W3C DOM. Our document intends for UA developers to implement the W3C DOM (core, CSS, etc.) This does not preclude a UA from adding additional function like Microsoft for highlighting text. A DOM is simply an object model representation of a document. I don't understand why an AT vendor would have trouble with this. Just because the W3C defines a standard one that we with UA's to support does not mean that an office product could not use a different DOM representation. ... but if you think some education is needed we might be able to do this through the WAI. Regarding interfaces, I had pushed on the PF group to create a sub-DOM working group to address user interfaces and was unsuccessful. It certainly would be nice to extend the DOM to the chrome of a browser. Perhaps Netscape could be the first. On an aside: If Freedom is parsing the HTML themselves this is a major work effort as they have to do error correction, etc. Also, if Freedom parses into their own DOM and due to different error correction techniques they have 2 different represenations of the same document you can run into more problems. This is also problematic for when XML-based formats need to be processed. It's much better if the UA provides a W3C DOM interface so that the solution is in synch with what is rendered and things like the core DOM API can be supported independent of whether the content is XML-based or SGML-based in the case of HTML. Rich Rich Schwerdtfeger Senior Technical Staff Member IBM Accessibility Center Research Division EMail/web: schwer@us.ibm.com "Two roads diverged in a wood, and I - I took the one less traveled by, and that has made all the difference.", Frost aaronl@netscape.c om (Aaron To: "Ian B. Jacobs" <ij@w3.org> Leventhal) cc: w3c-wai-ua@w3.org Sent by: Subject: Re: Issues and comments arising from UA evaluations w3c-wai-ua-reques t@w3.org 03/13/2002 03:40 PM Ian B. Jacobs wrote: - AT developers may not, in practice, be interested in implementing the DOM, even though in the past they have expressed interest. Freedom Scientific markets their products as making use of the DOM. However, they are not talking about the W3C DOMs -- they are talking about proprietary DOMs such as those that exist in Microsoft Word or Microsoft Excel via very powerful COM or ActiveX interfaces. For their Internet Explorer support they currently parse the HTML themselves. Anyway, I think what a "DOM" is, is clear to us in the context of W3C document, but may not be clear to AT vendors who use many different kinds of DOMs. They are probably interested in any kinjd of cross-process interfaces that give them content.. In addition, the W3C DOM does not say anything about user intefaces, unless they are written in markup, which is not always the case. How does the UAAG suggest we expose information about our user interface widgets? Aaron
Received on Thursday, 14 March 2002 10:58:48 UTC