Re: quick review of the UA guidelines section 5 (19990210)

Hi Mark,

Thank you for comments.

mark novak wrote:
> 
> Under 5.1, checkpoints for fonts and colors.
> 
> - do you need to say anything about being able to distinguish between
> visited and unvisted links, in the abscence of style sheets (noted later
> in section 5.3.6)

I'll add a cross reference.
 
> Under 5.1.7, checkpoints for applets and animations
> 
> - you may wish to consider changing the priority to #1, as people with
> photosensitive epilepsy may not be able to use the UA at all, unless they
> are assured that animations are turned off.

ISSUE to discuss during a teleconf.
 
> Under 5.1.10 , checkpoints for video
> 
> - do 5.1.1 thru 5.1.4 apply to the control and position of captions?

I'm not sure which checkpoints you're referring to 
(presumably in http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19990210/)
 
> Under checkpoints for audio
> 
> - do you want to suggest that audio tracks be "text" searchable ?
> - do you want to provide some audio feedback as to audio length, either
> before it plays, or when paused, etc. ?

ISSUE to discuss during a teleconf.
 
> Under 5.3, Ensure that links are accessible
> 
> 5.3.3, allow the user to search for a link based on its attribute values
> 
> - do you need to define "which" attributes can be used, given this is a
> priority #1 item ?

Good question. What do we do, for example, for XML applications.
One goal of this checkpoint is to find links based on the value
of the "title" attribute (e.g., when IMGs are in links). 

ISSUE to discuss during a teleconf.

> 5.3.4, Allow the user to move the focus to a link based on its integer(
> tabbing-order) position
> 
> -if I understand what this is allowing the user to do, I don't think we need
> this to be a priority #1, given the navigation and searching impiled in
> 5.3.1 thru 5.3.3

I agree. You can get to the link by tabbing. Direct navigation is
convenient, but the document is not inaccessible without it.

PROPOSED: 5.3.4 is a Priority 2.
 
> Under 5.4, Ensure that tables are accessible
> 
> overall, do you need to state something about a table being able to
> take "focus, or point of regard" via the keyboard ?  or is that implied in the
> fact that somehow you are going to be able to navigate a table, so it must
> have been able to obtain focus ?

This is a very good question, and one I've been struggling with.
I've been trying to think of checkpoints in a way that doesn't
necessitate having a table selection mechanism. For instance,
if you can navigate to a table, the selection mechanism is implied.
However, navigation among tables is not likely to survive as
a checkpoint, so I agree that there probably needs to be a checkpoint
about selecting a table.

The selection might be the mechanism used to indicate which table
has been selected, but the table identification mechanism is
probably independent of it. I think we shouldn't use focus
if it's implied that focus is for element activation.

I think this question also applies to table cells and forms.

Links and form controls are covered by the focus.

Note that such checkpoints used to be in the document.
See http://www.w3.org/TR/1998/WD-WAI-USERAGENT-19981112/

   [Technique: 5.5.3] [Priority 1] 
        Provide a mechanism for designating the current table of a
document. 
   [Technique: 5.5.4] [Priority 1] 
      Provide a mechanism for designating the current cell of a table. 

> 5.4.3, Allow the user to navigate amoung tables in a document
> 
>  - while helpful, I don't see this as being a priority  #1 item

In 25 Feb 1999 teleconf resolved to priority 2.
 
> 5.5, Ensure that forms are accessible
> 
> - should forms make mention or use of the AccessKey (this might be more of an
> implementation or technique issue)?

I'll add a cross-reference to the pertinent guideline.
 
> - while navigating among the form controls, should you say anything about
> that you are really navigating from label to label, but the focus or point
> of regard is positioned in the "TextField" of that control, thus a user who
> navigates to a form control of interest, is properly positioned to reply to
> that form control ? (this might be more of an implementation or technique
> issue)

Is it true that you navigate label to label? I would think you
would navigate among other form controls (perhaps including LABEL)
and that you would want access to the label for each control
(where specified explicitly).
 
> 5.5.4, Allow the user to seach for a form control based on its attribute
> values
> 
> - again, do you need to define which attributes, especially if
> this is a priority #1 item ??

Same issue as above.

Thanks again Mark,

 - Ian


-- 
Ian Jacobs (jacobs@w3.org) 
Tel/Fax: (212) 684-1814 
http://www.w3.org/People/Jacobs

Received on Saturday, 6 March 1999 13:54:45 UTC