WCAG 2.0 Draft Comments

Summary:

As part of the WAI-EO review, I prepared these comments -- which seem too
detailed for that audience, even though I sent an earlier version there.

I have enjoyed doing this review, and feel it addresses significant 
improvements
and clarifications to WCAG 1.0.

My comments are based on my linear reading, and further augmentation after
discussion during the WAI/EO meeting 2003/08-08 of:

     <http://www.w3.org/TR/2003/WD-WCAG20-20030624/>http://www.w3.org/TR/2003/WD-WCAG20-20030624/ 


Important issues I expand upon below:

1.  How does a user of assistive technology learn:
         what the style sheet does to make structural elements distinct?
         how to substitute a personally familiar one -- including use of 
hot-keys.

2.  Dealing with Acronyms/Abbreviations

Details:

Under bullet 1 of Benefits of Checkpoint 1.1

     "...have the text read aloud to them" [That suggests to me that it 
could be
read by a person, or pre-recorded narrative as in a digital talking book.]
Suggest add to end
     " using text-to-speech synthesis."

1 .3  1. c. any emphasis -- should user preference determine how to distinguish
among kinds of emphasis: e.g. by speech pace, voice, volume, or pitch shift.
Should the user be able to specify these distinctions?

One option would be to let the user have the choice to enunciate some or all
element names in tags.

That general issue of user learning the distinctions among markup warrants 
careful
consideration. How are header levels differentiated? Should the user have the
ability to inject personal preferences? [These are suggested later in 
Checkpoint
1.5 in the best practices.]

At a minimum, how does the user learn these distinctions? Should such 
explanation
be included by query for each document (or at least in some general 
guidance for
a collection of similar documents -- with a common style sheet.)  A simple 
document
naming and giving the presentation for each distinct structural form of 
markup would
be a useful aid, that probably should be included with each distinct 
style-sheet.

It would need to cover distinctions in list nesting of different kinds.
Also of table cell coordinate query and identification vs cell content.

Benefits of Checkpoint 1.4 ... Example 2:

the user should be able to get the Acronym and its expansion. Put in a
forward reference to where this is discussed in more detail in section 3.2.

Checkpoint  1.5

One user choice might be to have that encountered tag structure read, and
possibly some attribute values.

Another choice would be to limit the levels of detail, say by initial 
reading of
just primary heads, as if stepping through any table of contents, and then
dynamically when finding one of interest reading the sub-heads.

Best Practices for Checkpoint 1.6  ...

Gray Scale vs black and white viewing of a gray-scale image -- Is this
proposing a threshold, at some gray level to move to either black or white?
That level might well be a function of content. I'm not sure this is readily
determinable:  possibly use the "average" gray-density as threshold.

Would this be a user preference?

Guideline 2: OPERABLE. Ensure that Interface Elements in the Content are
Operable by Any User

Suggest "Interface Controls applied to the Content" instead of "Elements in
the Content" to avoid the common used of elements (or element tag names)
as the structure-conveying part of tagged documents.


2.   I note the grouping principle 7 +/- 2 as the human perceivable range of
choices.

3.1 Example 1 nit The French phrase starts with "je" which is omitted in its
second identification.

3.2 Extended definitions of Abbreviations and Acronyms -- discussed above
under Benefits of Checkpoint 1.4.   That should have a forward reference to 
3.2.

I question the assertion of unambiguous definition in the unabridged dictionary
for the language -- which rapidly ages. [No specific version remains pertinent
for long.] Computer jargon appears quite regularly and even may be 
transitory --
it disappears; or local to the current document.

Acronym expansion is important. It is probably contained in an attribute value
-- at least the first time;
and subsequently should be able to find that expansion -- by link to the 
original,
or often appropriately to a glossary entry, or possibly to a separate list of
Acronyms/Abbreviations.

A problem using any of the more general acronym/abbreviation finders
is that our jargon means what we want it to mean -- nothing more, nothing less!
The discussion of "unfamiliar content" addresses this issue.

That meaning is possibly quite different from what the general public might
perceive the meaning to be -- so we should check with such lists for conflicts
that could lead to confusion among our readers, some of whom may be
coming from different backgrounds.)

Checkpoint 3.1 [CORE] Language of content can be programmatically determined

If this were easy, I'd expect it to show up in spam filters! The language 
attribute
should be used to make this unnecessary, even for small spans within 
paragraphs.

Best Practices For Checkpoint 3.3

Nit: improved readability ?of vertical? lists might offer in place of long 
paragraphs of
information    ? omit "of vertical", replace by "structuring with"?

Benefits from Checkpoint 3.3

Example 2 -- unfortunate use of the ambiguous word "concrete!" I was expecting
the use of cement and sand and/or gravel!  -- as in "cast in concrete."

Non-text sounds   Suggest explicit inclusion of synthesized speech with its 
many
differentiating adjustments, and possibly event/tag announcer augmenting 
sounds.

Required for success of 3.4

Omit the ambiguous opening use of "Key" followed by "orientation and 
navigation."
Use "Important" instead.

Best Practices for Checkpoint 3.4

Use consistent "verb first" style for each list item.  About half now are 
passive:
... should be ...

4. [ROBUST] .. ROBUSTNESS [not ROBUSTABLE!] is more consistent with
PERCEIVABLE, OPERABLE, and UNDERSTANDABLE.

I have trouble parsing:

4.3 Technologies used for presentation and [for] user interface
[interaction should] support accessibility[,]
  or alternate versions of the content are provided that do support 
accessibility.

When alternative versions (not alternate -- means every other) are used, 
the dual versions
run the risk of inconsistency of updating. Therefore they are discouraged.

Glossary

Technology  -- suggest including

      operating system,
      assistive technology.

Regards/Harvey Bingham

Received on Friday, 8 August 2003 10:55:30 UTC