Re: Issues and comments arising from UA evaluations

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