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

Re: UAAG 1.0 WD 8 July 2002 comments

From: Ian B. Jacobs <ij@w3.org>
Date: Wed, 24 Jul 2002 20:11:55 -0400
Message-ID: <3D3F424B.5050003@w3.org>
To: Harvey Bingham <hbingham@ACM.org>
CC: w3c-wai-ua@w3.org

Harvey Bingham wrote:
> 
> 
> This as a neat document. I pick a few nits, some technical, some editorial.
> Editing convention I use: _insert_, XdeleteX.

Hi Harvey,

Thanks for sending in your review! I have snipped out
your editorial comments (and will incorporate them) or suggestions
for clarification.

> General:
> 
> It is not always obvious to me the separation of items listed under
> "Normative Inclusions and Exclusions." It is unusual in standards to
> imply something is normatively excluded.

We are saying what functionalities are "not required". Another way 
to talk about this is to say that something is "optional" (see
RFC 2119), but I find "not required" is clearer.

> Content:
> 
> 1. Introduction, bullets 4 and 5: Neither appendix is actually in the 
> document. Unusual.

They are appendices conceptually, but not in the same physical
file as the guidelines.

> 1.1 bullet 1, add CSS?

I don't know that that would substantially improve the document.

> 2. The user agent accessibility guidelines, second bulleted list, 
> bullets 6 and 7 ?normative?
> on sections beginning with Optional?? ?

Right. If they are there, they are normative. They are not
in every checkpoint.

> Normative Inclusions and Exclusions ... 3. Conformance Labels: Events   
> What does this
> mean? What must be normative? Are events included or excluded?

If you conform unconditionally, you support the events checkpoints.
But you may conform conditionally and not support them.

> Guideline 2. Ensure user access to all content.
> 
> 2.3 2 bullet 1 sub-bullet 4a  ...link _back_ to C from the context of D.

I don't think the word "back" is necessary or adds much to the
sentence.

> Sufficient techniques
> 2. To satisfy provision two, the user agent may provide access on a 
> per-element basis
> (e.g., by allowing the user to query individual elements) or for all 
> elements (e.g., by
> offering a configuration to render conditional content all the time.) 
> ?Shoudn't this be
> selective by element type, rather than instance thereof?

I think we meant element instances here: move focus, for example
to an element instance and query it. The element type information
may be useful in configuring structured navigation.

> 2.4 Allow time-independent interaction.
> Sufficient techniques
> 1. bullet  1 Alert the user that the rendered content has been paused 
> ...?Should the user
> be able to query the reason for the pause?

I think that that developers would explain why in the alert.

> 2.7 Repair missing content.
> Sufficient techniques
> 1. ...The user agent may satisfy this checkpoint by basing the repair 
> text on any of the following
> available sources of information: _attribute value_, URI 
> reference...[For example title="..."]

If there is strong support for adding this, I'm ok with it.
We had not decided as a group to include this in the list.

> 3.3 Toggle animated/blinking text
> 
> [What toggles? from animated to blinking!]

Does changing this to "animated or blinking"?

> ...at any rate of change, _lower than the screen refresh rate_, and 
> lower than the critical
> rate for triggering photo-sensitive epilepsy.

We discussed the definition of blink and chose
not to restrict requirement on blinking text to the range of 2 Hz to 
55 Hz (as is done in section 508). See issue 502 [1]

[1] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#502

> 3.6 Toggle images.
> 
> Sufficient Techniques
> 1. ...making images invisible, but this technique is not recommended.
> ? What is the expected behavior using alt="brief description" if images 
> are invisible?

That's either defined by the specification or covered by
checkpoint 2.3.

> Guideline 4. Ensure user control of rendering.
> 
> para 2...Users with color blindness may need to impose or prevent 
> certain color combinations.
> ? Does this mean that the user can specify color mapping onto portions 
> of the spectrum that
> are better distinguishable?

Yes.

> 4.1 Configure text size
> 1. Preserve text size differences when the user changes the scale  ? 
> Didn't we agree that
> the proportional change, rather than absolute point size difference, 
> should be permitted?

Yes, after the publication of this document. That change will
appear in the next draft.

> 4.5 Start, stop, pause, and navigate multimedia.
> 
> Sufficient technique. ?Advance three seconds?  I don't believe there is 
> any magic in that
> explicit amount. Cannot the user just "go forward", or "go backward" and 
> stop after the
> desired time interval? I expect the three seconds comes as a judgement 
> that that is
> a minimal duration to use.

The requirement is not to advance 3 second. The "that last three
or more seconds" qualifies the content. Brief sounds etc. are not
covered by this checkpoint.

> 4.9 Configure synthesized speech rate.
> 
> The user control of rate should be easily changed to allow the user to 
> skim fast, and slow down to study.

I am happy to add this to the Techniques document.

> 6.10 Timely exchanges through API*s.
> 
> "timely" is subjective, not quantifiable. As such it is no more than a 
> binary: can
> exchange or not.

This is a known feature of UAAG 1.0 (see issue 127 [2]). The UAWG
has chosen to leave this requirement in UAAG 1.0 with details
in the Techniques Doc to give an idea of what's expected.

[2] http://server.rehab.uiuc.edu/ua-issues/issues-linear.html#127

> 7.4 Provide input configuration indications
> 
> Normative inclusions and exclusions
> 
> For user agent features ?_affecting accessibility_?

That's interesting, but I'm not sure that it's desirable.
For instance, I don't see why the "print" function should be
less accessible because the developer didn't follow the
operating environment's input config conventions.

> 9.4 Restore viewport state history.
> 
> Normative inclusions and exclusions 1.
> How does user or unaided user agent know that prior content is "stale?"

Described in the Techniques Document:

     "1. Refer to the HTTP/1.1 specification for information about
         history mechanisms ([RFC2616], section 13.13)."

> 9.8 Provide text search
> 
> Some browsers provide search direction choice from present position, so
> can get to prior match more directly than return to start and go forward.
> I think this is desirable.

We chose not to require reverse search in this checkpoint. I don't
have a pointer to the decision, however. That functionality is 
listed in "Doing more" in the Techniques Document.

> 
> Should search be permitted to include content of alt text string?

We discussed this (issue 418 [3]) and concluded "only if
rendered." Hence the current wording of the checkpoint.

[3] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc2.html#418

> 9.10 Configure important elements
> 
> No mention of any importance conditioning based on attribute values.

I don't understand this.

> 10.7 Indicate viewport position
> 
> Normative inclusions and exceptions 1.
> For two-dimensional renderings, relative position inculdes both vertical 
> and
> horizontal positions. ?Does this suggest alternative presentation of 
> scroll bars?

Horizontal scroll bars are one way to indicate position in a
two-dimensional rendering, and that's required per this
inclusion. I'm not sure what "alterntive" presentation means.

> 11.3 Allow override of indings.
> 
> ?Should author-specified accesskey assignment (of 11.2) override user 
> binding?

This has been the requirement since the 28 July 2000 draft:
http://www.w3.org/WAI/UA/WD-UAAG10-20000728/

We resolved not to require override of author-specified bindings
at the 24 July 2000 teleconference:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0126

> Glossary
> 
> Add   Document Type Definition (DTD)
> as DTD as referred to alone and unexplained (for example, in Document 
> object, Document
> Object Model (DOM), and also in Element, element type.

I am happy to expand the acronym, but I don't want to define DTD.

> Add Keyboard equivalent

I don't think we need to define that. We explain in Guideline 6
that other ATs may use the keyboard API. We have no requirements
related to a keyboard equivalent.

  - Ian
-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Wednesday, 24 July 2002 20:15:09 GMT

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