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

WCAG 2.0 Draft Comments

From: Harvey Bingham <hbingham@acm.org>
Date: Fri, 08 Aug 2003 02:56:10 -0400
Message-Id: <5.2.1.1.2.20030808001004.00b71150@pop.rcn.com>
To: EOWG <w3c-wai-eo@w3.org>

Summary:

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

My comments are based on linear reading of:

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


Important issues:

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?

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, 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.

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.

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 to a possibly 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.)

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!

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 ...


Glossary

Technology  -- include operating system,  assistive technology.

Regards/Harvey Bingham
Received on Friday, 8 August 2003 02:56:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 10:33:36 GMT