- From: Ian B. Jacobs <ij@w3.org>
- Date: Thu, 16 May 2002 15:35:01 -0400
- To: w3c-wai-ua@w3.org
UAWG teleconference, 16 May 2002 Agenda announcement: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0089 Participants: Jon Gunderson (Chair), Ian Jacobs (Scribe), David Poehlman, Eric Hansen, Loretta Guarino Reid (Adobe), Cathy Laws (IBM), Jill Thomas (Ion Systems), Patrick Brannan (Ion Systems), Bill Haneman (Sun/Gnome), Philippe Le Hegaret (W3C), Rich Schwerdtfeger (IBM), Tim Lacy (Microsoft), Al Gilman, Jost Eckhardt (AI Squared) Regrets: Jim Allan, Harvey Bingham, Glenn Gordon, Roberto Gonzales. Previous meeting: 9 May 2002 http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0080 Next meeting: 23 May, 2pm ET. Regrets: Harvey (next 2 weeks) Reference document 12 September Candidate Recommendation: http://www.w3.org/TR/2001/CR-UAAG10-20010912/ ========== Discussion ========== 1. Issue 529: 6.1, 6.2: Is DOM required at P1, or some API? http://www.w3.org/WAI/UA/issues/issues-linear-cr2.html#529 See proposed resolution of issue 529: http://www.w3.org/WAI/UA/2002/04/api-summary (A few people have read the proposal before attending the call.) RS: PFWG did ask for rendering information about 1.5 years ago; no time to put into DOM. PLH: Views and Formatting is not being developed by DOM WG. No companies (other than Netscape, perhaps) are willing to work on this right now. AG: This is not a new idea. We have to take PLH's advice as the state of the world: you can't project any sort of delivery date out of DOM WG. PLH: As of today, we've received no input to continue this work. (IJ summarizes proposal) AG: A quick look at the proposal: a) Suppressing DOM where not normative bindings. Seems like it's on thin ice to say "use something like the DOM where non-normative bindings". Delete that. b) Adding access to rendering structure. RS: What I think is needed - UA developer needs to document bindings. UA developers needs to show how API maps to W3C DOM. IJ: We would require public documentation of API. RS: We understand that implementations of DOM may vary, so UA must document their implementation on W3C Web site. PLH: We do have a page to reference non-normative bindings on the W3C Web site. In the case of C++, we only had one submission (I think from Oracle). JG: Can we request that the DOM WG do this? RS: We can request that info be documented at UA Web site if not DOM WG Web site. BH: I think we have a deeper issue here than the question of bindings. I would want to avoid the unintended effect - if the DOM is stated as the API of preference for access to content, there is a possibility of a negative side-effect. It could encourage UA developers to provide access to content instead of view-based access. Different user agents will tend to interpret content and style sheets differently. Implementations are imperfect; legacy has an impact. Don't offload chore of calculating view from original content. Screen readers, if couldn't have direct view access, would have to extract information from the DOM. If we make the DOM the preferred method, we might discourage work on view API. BH: Is the IDL for DOM normative? PLH: We use the Corba IDL in the DOM Specifications. It is completely useless to try to use the IDL provided by the DOM spec in a Corba environment. We are only using it as an abstract language. It's not meant to be implemented client-side. Because of this, the OMG is providing their own bindings for the Corba environment. BH: Do we have normative bindings through the OMG? PLH: They do have mappings that are usable on the client side. But if you try to use this IDL (e.g., in C++), it's unusable. The OMG stuff is for client-server communication, not really for client-side. I recognize there are some use cases. But I think that Web services and other new technologies will obviate some of this; bits will be replaced by XML. PLH: I have a couple of comments: a) On access to views - I recognize that this is necessary when you really want to know what's on the screen. But when you access the views content, you lose structure. In the best case, it will be a set of boxes. But clearly there are cases when you need to know what's on the screen. The DOM 3 Proposal for user formatting was trying to address this use case. BH: It's not necessary for the view to be flat. PLH: Yes, it can have some structure, but it may not have any meaning. E.g., CSS absolute positioning will render some boxes meaningless other than their position on the screen. Also, for SVG or X3D content, you don't even know how your rendering structure will be represented. So the term "rendering structure" is vague. PLH: (b) Regarding the DOM and the problem between an invalid document and the rendering structure - usually the parser does some repair. PLH: (c) I think it is important to distinguish between normative DOM bindings and non-normative. You should require DOM for Java/Ecmascript since that promotes interoperability. RS: Yes, you need access to doc structure for more complex formats like SVG. Even for non-normative bindings, DOM is important. I understand that you will not have a standard C++ binding. Solve this by requiring UA developers to document their DOM binding. But still require the DOM API be implemented. BH: What a sighted user interacts with is only implicit structure; it's visual structure. This is obvious, but significant. What we are aiming to do (at least what we hear blind users are asking for) is to know what's on the screen. IJ questions: Is there anyone who thinks we *should not* have a requirement for access to structure? BH: I don't think it needs to be a P1 requirement. It's unclear to me how, in the general case, access to the DOM gives you what users want to know. Low vision, blind users want access to screen information. JG: Our requirements are not to manipulate the DOM, but to give ATs the means to perform functions through a standard API. BH: Sighted users want to use the GUI that's on the screen. PLH: I disagree with this; when I want to add a paragraph to my HTML, I would do this in a programming environment through structure, not a view. DP: I think there's a piece missing in BH's scenario: What we have here is an attempt to provide AT developers with a unified way to provide information to the users of the AT. That information can be provided in such as way as to allow a person to manipulate graphical elements (whether handed to the AT by the UA's use of the DOM or some other method). What the user wants is the ability to interact with the content being delivered. What UAAG 1.0 tries to provide is a way to achieve this without AT vendors trying to invent a way to do it. BH: There are APIs. New ones. The concern I have is that the DOM doesn't help AT developers do what they need to do. DP: AT developers are using the DOM and supplementing it. PLH: I have a problem understanding why AT developers need access to views. BH: This is about users using visual user agents more effectively -- off-the-shelf software. JG: As we move forward, DOM access to XML will be more important (and XML content will be valid). JG: Henter-Joyce looks at content (DOM) and can extract accesskey information that is provided to user in a separate document. DP: And heading-level information. BH: Structure information is important, but what I think the user really needs is a DOM for the view. IJ: Balance between content / view access is what our proposal is. BH: I'm still troubled by content requirement; big burden that detracts from effort for providing access to view. I wouldn't want a UA to not be able to conform, while providing structured view access and streaming access. PLH: Mozilla has DOM bindings in Linux. BH: But you don't have a good way of exporting that out of process. JE: We do both. CL: We embed the browser control in the HPR process. BH: Not the case with AT vendors we're working with. All going on out-of-process. The goal is to have ATs working for the entire desktop. IJ: We promote DOM specifically for Web content. BH: As long as the need for view is recognized, I'm satisfied. But I still feel that implementation will be a burden. BH: 508 also puts a higher accent on identification of what needs to provided. Resolved: - Add a P1 view requirement. - Require DOM for access to XML/HTML content in java/ecmascript environments. BH: For third point (non-normative bindings), we would prefer not requiring following DOM and publishing DOM bindings. PLH: I agree with BH on this (i.e., support JG/IJ proposal and not RS's). LRG: If someone has implemented the DOM, they have to do additional work to expose the view information. Too bad these can't be tied together. We've documented an API for access to rendered information (MSAA). We'll probably do something similar to what MS has done - tie MSAA and DOM together. TL: IE exposes view information. JE: Structured view information is more useful than just pixels. It is helpful when view information connects to the structure. PLH: It's not always possible to map from rendering information to structure. E.g., a document transformed through XSLT. No way to guarantee mapping back to structure. Also, some style languages (e.g., css) add content; no way to connect that to a DOM constructor. TL: The markup, regardless of format, can be accessed through an interface, but it's not structured; it's a stream. BH: When I say "structured view", I'm talking about something that's not just pixels. You have a hierarchical object model with attributes. There are cases where it's not difficult to give structured view access. Frequently, in a UA, you have a content DOM, but the renderer looks at some intermediate format that is no longer the content DOM. Or, if the UA is using a standard set of building blocks (e.g., for displaying paragraphs, images, etc.), then the renderer can provide the same level of abstraction. IJ: We could say "pixel access alone is not sufficient." /* BH leaves */ PLH: Another problem of view-only access - there may be some cases where someone wants access to something that's in content but not rendered. In my opinion, having content without view information is not a good idea. If I had to choose one, I would choose DOM over the view access. JG: Suppose I'm developing an XForms application. I may have to retrieve a bunch of XML documents to understand how an xforms app is rendering a form. PLH: The only thing the DOM provides you by default is access to the XML Infoset. If you have a schema attached to it, the DOM will not give you access to the Schema. Yes, a generic application may need to download a series of XML documents. There is some discussion currently whether we should be able to access the result of the XML Schema validation (and not just the DOM). Being able to replicate an XML Schema validator is not something you would want an AT to have to do. But view information will not help solve some issues either. JG summarizing: We have everything from wanting to know pixels to knowing actual content coming down the pipe to the system. We need to take back and look more closely at various needs of different types of ATs and browser technologies. JG to CL: If you get XML content, what do you do with it? CL: We convert everything to HTML first. We don't handle MS Office content through the DOM. Just as a screen reader. We only handle HTML or text document in graphics view. We are having problems handling anything that's not HTML right now. We have different parts of HPR: we have a little screen reader that reads non-HTML. But we don't have a way (yet) of how to pass focus to these things. JG: Have you explored working with Powerpoint? CL: No. PLH: I have some concerns with direction of UAWG: you can't evaluate all use cases. If you have HTML+SMIL, you will want to have access to the timeline. IJ: Today, we require access to UA functionality (e.g., to pause). PLH: In the case of xforms, you'll want to access data types. And so forth, for each type of XML application. If you go down this path, you'll have to consider all types of XML applications and find use cases for them, and require APIs for all of them. JG: What if we have no example of an AT using DOM for access to XML content? Does Henter-Joyce parse other types of XML? We heard that HPR is not accessing XML content? We don't have an example of ATs finding this useful today. PLH: What about Adobe implementation of SVG? They provide DOM access to SVG. People are accessing any kind of document through the DOM. The Adobe plug-in is one example. JG: I just want to voice some concerns that we have requirements that some AT vendors are not finding useful. We know of many cases for HTML content where access to content is useful. We hope the same for XML, but haven't seen any implementations by AT developers. If we ask UA developers to do things, we want to be sure that there are people at the other end to receive the data. IJ: Do other people feel like Jon that since we don't have more XML experience, we shouldn't make any XML requirements (through the DOM)? DP: I suggest taking this to the list. From the survey we sent to AT developers, I wonder how we can meet those needs. IJ: We have heard resoundingly the need for access to content (XML or not). We are only saying here that people should use the very best API to promote interoperability. I realize that there are CR issues (implementation experience). JG: I just want to ensure that when we go to the Director, we can say with confidence "AT developers want this, even if they need to catch up." ----------------- Completed Action Items ----------------- IJ: Send proposal for Guideline 10 modifications based on today's teleconference Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027 Done: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0081 IJ: Propose text to the UAWG on conformance profiles for use by other specifcations. Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027 Done: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0083 ----------------- Open Action Items ----------------- IJ: Review UAAG 1.0 for which checkpoints should be "all formats" v. "formats that are part of the claim". http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0049 Status: Pending. JG: Write up user scenarios for why non-text-based highlighting important for users; notably which users. Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0027 See for additional questions: http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0029 JG: Clarify why "Max rating" used in some cases (in low implementation experience section) and "Avg rating" in some cases. Also, delete "+/-" with P (round down from G to P) http://lists.w3.org/Archives/Public/w3c-wai-ua/2002AprJun/0049 JG: Contact developers for API requirements -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs Tel: +1 718 260-9447
Received on Thursday, 16 May 2002 15:37:10 UTC