- From: Harvey Bingham <hbingham@acm.org>
- Date: Fri, 08 Aug 2003 10:49:22 -0400
- To: w3c-wai-gl@w3.org
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