Re: From talking to developers...

charles@skip.w3.org wrote:
> 
> Dear all,
> 
> I have had meetings with some developers this week, most notably from
> Internet Explorer and Real Player. With luck we will have a rough
> conformance evaluation from each of those groups, but there were some
> checkpoints that raised questions, so I am listing those here. (They have
> the same order as in the checklist of the 25 january draft).

Thanks Charles.

My comments below.

> 
> Checkpoint 2.2: For presentations that require user interaction within a
> specified time interval, allow the user to configure the time interval
> 
> Does a pause function satisfy this?

The note in the checkpoint says it does. Was the question whether
that really addresses the issue?
 
> Checkpoint 3.3: allow the user to turn on and off rendering of video
> 
> In a window-based environment, is it satisfactory to hide the rendering
> window, or does there have to be control over the video rendering
> separately to other parts (e.g. caption track)

My first reaction is that hiding does suffice (the issue is distraction,
isn't it? Not one of performance where you might want to stop the
processor from handling video). If the caption is part of the video
(i.e., a single track with both), I don't know how you could still
have the captions if you turn off the video. If there are separate
tracks, you should be able to view captions alone.
 
> Checkpoint 4.5: Allow the user to slow the rate of audio, video and
> animations
> 
> In the case of animations, does this mean a requirement to step through or
> slow the speed as well as being able to turn it off? (My own thought is
> yes - if there is content in an animation it is important to step through
> it).

Yes. One question: do you think it's a violation of a spec (e.g.,
GIF) to control the rate of the animation? Note that our applicability
clause would cover this case; the user agent doesn't have access to
the properties of the content (i.e., might not be able to regulate the
speed). 


> CHeckpoint 7.2: For user agents that offer a browsing history mechanism,
> when the user returns to a previous viewport restore the point of regard
> in the viewport.
> 
> In a timed presentation does this mean return to the time that the user
> was at (where possible - it wouldn't necessairly work in live streaming
> for example)

If the technology doesn't allow, then the requirement wouldn't apply.
Otherwise that's a good point and should be mentioned in the techniques.
 
> Checkpoint 1.5: Ensure that the uesr interfaces provides information
> through redundant output modes
> 
> This could be worded a bit more clearly.

Any suggestions?
 
> Checkpoint 6.2: Conform to W3C specifications when they are appropriate
> for a task
> 
> It is a bit unclear how to verify when the specification is appropriate to
> the task. Is the requirement to conform to the specification, or is it to
> use appropriate W3C specifications for graphics if you render graphics, or
> is it both requirements? (Actually, if it means use W3C specifications
> does it mean exclusively, or does it mean include handlig of those?)

I think it's both. I propose this clarification:

   "Use and conform to W3C specifications when they are 
    available and appropriate for a task."

We could drop the conformance part, but the whole reason we're
pushing them is that they promote interoperability and have
accessibility
built-in. If you don't conform, what's the point? I do recognize that
conformance is hard in some cases. It makes that the conformance part
is P2. 

As to the exclusive part, I don't think that's implied. However, for
checkpoint 11.1 we do make the clarification that there must be "at
least one"
version of the documentation that's accessible. We might make a similar
clarification in the checkpoint or a note after.  
 
> Checkpoint 10.7: Allow the user to configure the User agent through a
> profile
> 
> It is not clear what the minimum satisfaction is - allowing the user to
> configure their name? The window size? at least both of those? Use a local
> CSS stylesheet?

That is true. A couple of ideas:

1) Demote to P3 and the text as is.
2) Identify the key requirements, for example presentation and input
   configuration. 

> 
> Checkpoint 8.4: Make available to the user information that will help the
> user decide whether to follow the link.
> 
> Does this mean make available all the information the tool has? Or just
> some of it?

Since it's a P3, why not all of it?

> 
> Checkpoint 10.8: Provide default input configurations for frequently
> performed tasks
> 
> There is by definition a default input configuration. The wording of the
> checkpoint itself (rather than the additional information) should make it
> explicit that what is required is a "simple, obvious, rapid method" to
> activate the functionality.

I propose the following clarification:

1) I think "a default input configuration" makes more sense than
"default
   input configurations" since there is only one default. Even if
several
   modes may be covered (voice, keyboard, etc.), there's still only 
   one default input configuration.

2) Every browser comes with a default configuration. What are we
   requiring exactly?

   I propose that 

    a) Either we drop this checkpoint, or
    b) We make the requirement much more specific. For example:
       "Ensure that the default configuration allows the user to
navigate
        content and user interface controls simply, obviously, and
        quickly." 

 - Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814 or 212 532-4767
Cell:                        +1 917 450-8783

Received on Sunday, 6 February 2000 06:16:14 UTC