Re: UAAG review comments (Fwd)

"earl.johnson" wrote:
> 
> Hi Ian,

Hi Earl, 

Thanks for the review. I will incorporate editorial comments
and otherwise add your issues to our issues list:
  http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html
 
> The following are Sun's comments for the final review period of the
> UAAG. The core team has done a very good job pulling them together and
> making them relevant, thanks to all of you for your efforts.
> 
> Sun Microsystems approves this last call version of the UAAG and
> respectfully asks you to consider the following mostly minor
> comments.
> 
> For Sun Microsystems,
> 
> Earl Johnson
> 
> ---------
> 
> 2.3 ...
>         Recommend rewording to "Provide easy access to at least one
>         ..." and/or changing "... equivalents; 4) ..." to "...
>         equivalents; or 4) ..." as it is used in the checkpoint's
>         example.
> 
>         Also, is there one that must absolutely be supported or that
>         provides biggest impact on delivery of equivalent access to the
>         user? This is asked because it would be bad if there was one
>         clear must have the developer should know about but they pick
>         another less effective one because they think the list isn't in
>         a prioritized order.

I've added to the issues list. 
 
> 2.5 ...
>         Does the Techniques for this checkpoint show how to meet this
>         checkpoint or is there HTML/XML/? supported ways for making
>         sure repair can happen? Appologies if this is answered in the
>         techniques for this checkpoint, it couldn't be verified because
>         going there keeps crashing the reviewer's UA.

Ok, we can add to techniques an example.
 
> 3.2 ...
>         It's not clear what the term "placeholder" means. Consider
>         adding a definition of it to the Glossary.

Issues list.
 
> 3.3 ...
>         Assuming this checkpoint covers it, recommend adding an example
>         note that includes a stock quote ticker and/or ad banner so it
>         is clear these fall in this realm. Appologies if this
>         suggestion is addressed in the techniques for this checkpoint,
>         it couldn't be verified because going there keeps crashing the
>         reviewer's UA.

Issues list.
 
> 4.1 ...
>         Thinking of lo vision, where do graphics such as logos,
>         pictures, and diagrams fit into this guideline? Do they or is
>         this a separate case? SVG is mentioned in the Note: but it's
>         not clear that mention is meant to cover these (the checkpoint
>         refers to text not graphics, especially those that convey
>         meaning).

The requirement to resize non-text content has been explicitly
cited as an out-of-scope issue for this version of the
document. From section 1.2: 

  "This document does not in general address
   control of the size and color of rendered non-text content. "
 
> 4.11 ...
>         A person who can hear knows when the audio stops so they can
>         know when to move onto their next task. Turning off the volume
>         takes that cue away from the user who can hear and gives no
>         indication to the person who can't hear when audio is stopped.
>         On Macs, when volume is turned off, an audible tone is instead
>         represented as a screen flash. Should an equivalent "provide a
>         visual indication when audio ends (and begins?)" be added to
>         this checkpoint or is a new checkpoint covering this needed?

Can you explain a little bit more the scenario you're referring to?
What case are you talking about where the user advances from task
to task based on audio cues (or knows to advance when audio stops)?
Would this be covered by checkpoint 1.5 : each message that is
a non-text element and in the UI must have a text equivalent?
 
> Under UI checkpoints for guideline #4 ...
>         A regular access related guideline in UI styleguides is that
>         the size of the components should scale when the size of the
>         object it contains (e.g. a lable or graphic) changes. This
>         point doesn't seem to be reflected in any of the checkpoints in
>         this section. Consider adding this point to an existing
>         checkpoint or crafting a new one specifically for it.

I will add to the issues list.
 
> 5.4 ...
>         This reads like a UI not content related checkpoint. Recommend
>         making this more clearly a content checkpoint or moving it into
>         the UI section of checkpoints.

It's in the section entitled "checkpoints for communication with other 
software", which seems better than either content or UI. Does that work?


>         Also recommend moving the example contained in the checkpoint
>         down into the "Note: For example ..." portion of the checkpoint
>         to match the style of the guideline's other checkpoints.

Issues list.
 
> Under UI checkpoints for guideline #5 ...
>         Recommend adding a checkpoint of the type 5.4 presents in the
>         UI section.
> 
> 8.5 ...
>         Does the current HTML/XML/? spec and language provide
>         mechanisms authors can use (and UAs can refer to) to provide
>         the information called for in this checkpoint or are they on
>         their own to figure how they provide (author) and where to go
>         to get this info (UA)? If no, consider removing this checkpoint
>         till support for where to provide it is available. Appologies
>         if this is answered in the techniques for this checkpoint, it
>         couldn't be verified because going there keeps crashing the
>         reviewer's UA.

Issues list.
 
> 9.7 ...
>         Saving user preferences is an important usability requirement
>         that every user has, it goes far beyond accessibility. Consider
>         bumping this checkpoint up to a P1.

Issues list.

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Tuesday, 14 November 2000 22:09:27 UTC