W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2002

Re: HTML WG last call comments for UAAG 1.0

From: Ian B. Jacobs <ij@w3.org>
Date: Tue, 24 Sep 2002 15:57:06 -0700
Message-ID: <3D90EDC2.1000800@w3.org>
To: Jon Gunderson <jongund@uiuc.edu>
CC: Steven Pemberton <Steven.Pemberton@cwi.nl>, w3c-wai-ua@w3.org

Jon Gunderson wrote:
> 
> Steven,
> 
> Thank you for your review and here are some initial comments.

Yes, thank you Steven for doing this. My comments below.

  - IAn

> Jon
> 
> comments in JRG:
> 
> At 11:47 AM 9/24/2002 +0200, Steven Pemberton wrote:
> 
>> I hear you are planning to move straight to PR. What are the CR exit
>> criteria, and how do you measure that they have been met?
> 
> 
> JRG: The same as other groups.  Two independent implementations of each 
> requirement.  Although we may need to ask for exceptions for a few 
> requirements, that have low implementation.  See implementation report:
> http://www.w3.org/WAI/UA/impl-pr2/
> 
> Right now we have 2 implementations for about 92% of the requirements.
> 
>> Guideline 1. Checkpoint 1.2
>>
>> "Allow the user to activate, through keyboard input alone, all event
>> handlers that are explicitly associated with the element designated by 
>> the
>> content focus."
>>
>> *all* is a bit overkill here. For instance XForms allows event 
>> handlers for
>> events that are part of the processing model. These events are not 
>> caused by
>> the user, and are not intended to be fired by the user, and Forms 
>> processing
>> would be seriously disturbed if the user could activate handlers when 
>> these
>> events had not been fired. I would specify here "all event handlers for
>> events that could be caused by direct user interaction", or some such.
> 
> 
> JRG: This needs to be clarified for events that can be fired through 
> user interaction.

Yes, I think this is a bug in the spec. 9.6 says "the list of input 
device event types", and the previous version of the spec (the
CR draft) says: "any explicitly associated input device event 
handlers", and the second provision only talks about input
device event handlers.

So this is just a bug that should be fixed per SP's suggestion.

>> Guideline 2. Checkpoint 2.2
>> "For the purposes of this checkpoint, a text format is any media object
>> given an Internet media type of "text" (e.g., "text/ plain", 
>> "text/html", or
>> "text/*") as defined in RFC 2046 [RFC2046], section 4.1."
>>
>> Therefore not XHTML, which has media type application/xhtml+xml. I would
>> beef up this definition to at least include XML.
>>
> 
> JRG: Thank you for the suggestion.

Yes, I agree that that update is appropriate.

>> Guideline 3. Checkpoint 3.3
>>
>> "Blinking text is text whose visual rendering alternates between 
>> visible and
>> invisible, at any rate of change."
>>
>> And so not blinking between different colours?
> 
> 
> JRG: Good point, we want to cover this too.

"Between two colors" seems like a generalization of
"between one color and the background color", which is
what 3.3 currently says.

>> Checkpoint 3.5
>>
>> "Authors (and Webmasters) should use the redirect mechanisms of HTTP 
>> instead
>> of client-side redirects."
>>
>> I'm not sure what this means. is <meta http-equiv="..." /> a redirect
>> mechanism of HTTP?

No, that's browser-specific behavior that is not the same
as an HTTP redirect.

 > What if I don't have access to HTTP redirects? Is that
>> covered by the 'should'?

Yes, that's covered by the should.

>> "For example, if an HTML author has used a META element for automatic
>> content retrieval, allow configuration to override the automatic behavior
>> with manual confirmation."
>>
>> I don't understand this.
> 
> 
> JRG: Refresh can be disorienting to some users with disabilities and the 
> refresh needs to be controlled by the user

Proposed clarification:

  "For example, if an HTML author has used a META element for
   automatic content retrieval, the user agent should allow
   configuration to stop the automatic retrieval. Users can
   retrieve the content manually (e.g., "reload").

>> Guideline 4. Checkpoint 4.3
>> "greys": I don't care, but pub rules says this should be "grays".

Point taken.

>> Checkpoint 6.2
>> "This checkpoint is stands apart from checkpoint 6.1": syntax error

Yes.

>> Checkpoint 6.6
>> "The user agent is not required to provide notification of changes in the
>> rendering of content ... unless the document object to make those 
>> changes."
>> Syntax error

Yes. Should be "unless those changes affect the document object"
or something similar.

>> Checkpoint 6.8
>> "Support for character encodings is important so that text is not 
>> "broken"
>> when communicated to assistive technologies." Please use a better 
>> expression
>> than "broken". E.g. "so that text is correctly communicated to assistive
>> technologies".

Yes. I think "broken" came from Martin Duerst a long time ago. :)
(Issue 327)
http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#327

>> Checkpoint 6.9
>> "Export the normative bindings specified in the CSS module of the DOM) 
>> Level
>> 2 Style Specification" Mismatched brackets

Yes.

>> "For the purposes of satisfying this checkpoint, Cascading Style Sheets
>> (CSS) are defined by either CSS Level 1 [CSS1] or CSS Level 2 [CSS2]."
>> Why not state "any level of CSS" so you don't have to republish when 
>> level 3
>> comes out?

We don't want forward references. We'll republish if we need to.

>> Checkpoint 11.4
>> Would an emacs-like method of typing "escape" to go into single-key mode,
>> and then letting you type a single single-key be allowable here? 

Yes.

 > Or do
>> you
>> have to be able to toggle into and out of single-key mode explicitely? I
>> couldn't tell.

I don't think we have much more detail on this; what problem
do you see that is not solved?

What you described satisfies the language and I think intent of the 
checkpoint.

>> Checkpoint  11.5
>> "interrupt a request to reload a resource;" => interrupt a request to 
>> load
>> or reload a resource;

Yes.

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Tuesday, 24 September 2002 19:01:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:51:11 GMT