Re: UAAG 1.0 WD 8 July 2002 comments

"Ian B. Jacobs" <[email protected]>
Newsgroups gmane.org.w3c.accessibility.agents
Organization W3C
Message-ID <[email protected]>
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 ([email protected])   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.