- From: Ian B. Jacobs <ij@w3.org>
- Date: Wed, 24 Jul 2002 20:11:55 -0400
- 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 UTC