- From: Ian B. Jacobs <ij@w3.org>
- Date: Thu, 14 Mar 2002 13:57:01 -0500
- To: Jon Gunderson <jongund@uiuc.edu>
- CC: w3c-wai-ua@w3.org
Jon Gunderson wrote: > Responses in JRG: > At 03:26 PM 3/12/2002 -0500, you wrote: > >> Dear UAWG, >> >> A number of issues about the UAAG 1.0 Candidate Recommendation >> [1] have come up during recent reviews with developers. Most >> of these issues only require clarification. However, there are a >> couple of proposals for more substantial changes below that >> I'd like to discuss at an upcoming teleconference. >> >> Jon, I don't suggest that we add these to the issues list until >> the UAWG has had a chance to discuss them. >> >> Comments welcome, >> >> - Ian >> >> [1] http://www.w3.org/TR/2001/CR-UAAG10-20010912/ >> >> ============= >> From the (incomplete) RealNetworks review: >> >> 2) Add a section to the document explaining how other >> specifications can create profiles of UAAG 1.0 >> conformance. For instance, if the FOO specification wants to >> require FOO user agents to conform to UAAG 1.0 in a >> particular manner, what should/must the FOO spec say? >> >> Proposed: I would like to write this up and send to the >> UAWG in the near future. > > > JRG: I think this is good, but I think it would be good to work with > another working group trying to do this as part of the process. Seems reasonable. >> 10) Checkpoints 6.2 and 6.3 (DOM write access and >> programmatic access to other types of content): >> there is some content where it's a security issue >> to provide *any* kind of programmatic access. [Tantek >> made similar comments during the Mac IE review.] >> >> Some ideas for dealing with this: >> >> a) Provide programmatic access, but when security >> is an issue, prompt the user for confirmation >> (on configuration). >> >> b) If the user agent has a mechanism for allowing trusted >> programmatic access, then ATs should use this mechanism, >> and the UA must make available all content to these >> trusted agents. > > > JRG: We have pretty limited write access requirement. In forms it is > primarily to the value attribute with only the allowed values defined by > the author, since this is all any user gets to modify in the form. We > don't allow the user to add nodes or change the type of control, becasue > the user does't. Even though we have limited write access requirements, our assumption was: "If someone can do it through the GUI, they should also be able to do it through GUI extensions, and thus we require that the functionality be available through an API so extensions can be added." However, this assumption doesn't seem to work for some developers in some cases, for fear of malevolent agents using the same API. Very analogous to this issue is that of digital property rights: some players are willing to render graphically but not make available the same source content through an API for fear of easy copying. > >> 11) Checkpoints 6.1/6.2: Is it a P1 to implement some API >> and P2 to implement the DOM 2 Core? See my additional >> thoughts below. > > > JRG: I think we have put this one to rest many times, is there new > information? Some notes: a) My apologies, first of all: I was starting to think that a developer could implement a specific DOM (e.g., HTML) without implementing the Core module, but I've confirmed with Philippe Le Hegaret (DOM WG Chair) that the Core is always a prerequisite. So our requirement for the Core is indeed minimal (and necessary). b) There is evidence that more and more user agents will be implementing the DOM 2 Core (e.g., Mozilla, Adobe SVG plug-in), so that's "good news" in terms of our current requirement. So that's the "good news". On the other side: c) Do we have evidence that AT developers are starting to implement the DOM in response to increasing DOM implementations in user agents? Is there evidence that our requirement is promoting interoperability? I realize it is *intended* to, but if the reality is otherwise, and interoperability would be improved by our "endorsement" (indirect as it may be) of existing APIs that work, then maybe we should consider allowing other APIs than the DOM for content access, as long as those other APIs are: - Public - Designed for interoperability with ATs. As we have done in the past, we should poll AT developers, see where they are and where they are going, and take that information into account. >> 12) Checkpoints 6.1-6.4: Perhaps it's better (though not >> necessarily simpler) to express these checkpoints as >> functional requirements. It may turn out that the >> functional requirements are met by implementing >> some piece of an API. > > > JRG: Aren't they functional requirements now? It depends on the viewing angle. "Implement this API" is not as functional as "ATs must have access to markup, messages about changes to content, style information, and have information about incremental changes rather than being required to reparse an entire document after any change." If we took a look at the very specific requirements for communication with ATs, we might find that the API in question is larger than what we need. Even if we conclude that it is, we may not want to make any changes: it may be simpler and more realistic to say "Implement the DOM 2 Core" than to try to identify and qualify smaller pieces. In the past, we have at times given up trying to limit ourselves "strictly" to something that will benefit accessibility and loosened our requirements since then they tend to fit more naturally into broader development plans. And accessibility gets implemented along with everything else. - Ian -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs Tel: +1 718 260-9447
Received on Thursday, 14 March 2002 13:56:57 UTC