W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > September 2004

GG Comments on 07/30 WCAG Working Draft

From: Greg Gay <g.gay@utoronto.ca>
Date: Tue, 07 Sep 2004 17:50:26 -0400
Message-ID: <413E2D22.9030604@utoronto.ca>
To: public-comments-wcag20@w3.org, Greg Gay <g.gay@utoronto.ca>

I probably could have spent much more time reviewing, but have to get 
back to the other work that's been gathering.

Overall I see good progress from the previous review. There are still a 
few areas that have me worrying about the effects they will have on our 
evaluation practices. Namely:

Design principle 4 "...current and future technologies. (what about 
slightly older technologies?)
3.1 Level 3 regarding meaning and language use.
4.1 using (non w3c) technologies to specification

Comments below
WCAG 2.0 Draft 07/30/04 Comments.

Conformance Section:
Level 1 & 2 success criteria typo "be"
The importance of WCAG 1.0 priorities were clearer through the use of 
words like must, should, and may. These words were helpful for 
describing guidelines to clients and novice users. In WCAG 2 these words 
might be minimal, increased, and enhanced accessibility. Bold those 
words to create parallels  between meanings in the priorities of WCAG 
1.0 and Levels in WCAG 2.0. It might be helpful to distinguish levels of 
accessibility along a continuum from innaccessible and unusable to fully 
accessible and highly usable (0, 1-, 1, 1+, 2-, 2, 2+, 3-, 3 ,3+). Level 
1 and level two criteria address more basic accessibility requirements, 
with level 2 addressing some usability issues as well. Level 3 would be 
more focused on the trailing end of the continuum which deals more with 

Conformance Claims

authored unit == statement of scope "2. The base URI and a statement of 
scope describing the content to which conformance does and does not apply"

Include the date at which the conformance claim was made. For many sites 
content changes daily, and in many cases in our experience, content 
posted after the conformance date is often non-conformant. This is 
particularly important for reviewers, whose reputation can be damaged if 
nonconformant content is posted after a conformance review has been 
completed. In many cases a conformance claim can only apply on the date 
it was issued.

4. The date on which the conformance claim was made.

Overview of Design Principles
Regarding "robust" in principle 4, in WCAG 1.0 one guiding principle was 
to make content accessible for those who were not using "current and 
future technologies". I think this principle should include robust with 
regard to backwards compatibility. I do agree however that  limitations 
need to be set on the range of older technologies that should be 
supported. In many, if not most cases, users are not using current 
technologies. Either include a range for backwards compatibility, or 
define "current" to include say 5 years of older technologies. I don't 
know how to best define current, but in most cases between 5 to 7 years 
old roughly represents old technology (or obsolete technology) when 
matched against the rate at which technology is evolving.

Guideline 1.3
I'm not clear on the difference between 1.3 level 1 #3 and level 2 #1 
(i.e. ...also available without colour). An example distinguishing  
between interpreting markup, and not interpreting markup might clarify 
this confusion.

Guideline 1.4
See: Chris's colour experiment. AERT

Guideline 1.5
Level 3 - How would the average person measure a difference of 20 
decibels between foreground and background sounds? (perhaps the reason 
this is a level 3)

Would a transcript or caption be sufficient where it is not possible to 
distinguish foreground/background audio? For example,  producers will 
often add captioning to video where the speaker's voice is not clearly 
audible for some reason, or perhaps where a speaker has a thick foreign 
accent that is difficult to understand for native speakers. If guideline 
1.2  level 1 and 2 are met, then 1.5 level 3 might be considered 
irrelevant. If the author has provided synchronized captioning or a less 
desireable transcript, they should not be penalized for poor quality 
audio/video where foreground and background audio are difficult to 
distinguish, or is outside their control.

" ...with the exception of occasional short sounds." creates a 
subjective decision " ...what constitutes a short sound?" An example 
comes to mind -- an announcer is interviewing a spectator in the stands 
at a sporting event, when the home team scores a goal -- the sound of 
the crowd drowns out the speech of the announcer for 15 seconds, so the 
producer adds a caption so the inaudible speech can be read. Is the 
producer still penalized because the speech is not 20 decibles higher 
than the crowd roar? Perhaps this guideline could be refined to 
distinguish between sounds that are under the control of the producer 
and sounds that are not, or naturally occurring sounds.

Level 3 #2 might read:
2. Where the difference between naturally occuring foreground and 
background sounds is less than [20 decibels], or are indistinguishable, 
provide a caption or text alternative.

Who benefit for 1.5
"Individuals with hearing impairments  that limit their ability to hear 
all of the frequencies..." would be better as "Individuals who have 
hearing impairments that limit their ability to..." it is otherwise not 
immediately clear what the word "their" is referencing. e.g. individuals 
that limit their ability... or hearing impairments that limit their 

Guideline 2.1
Level 1 #1 I'm not sure  what might constitute functionality that "can 
not" be described in a sentence.

Level 2 #1 Could an exception be onclick? In reality onclick is used in 
a divice independant manner despite "click" suggesting it's mouse 
dependant. What makes an event handler abstract? Perhaps simpler 
language could be used here such as "...use event handlers that do not 
rely on the presence of a specific input device..." or"...use event 
handlers that are accessible to all input device..."

Level 3 #1 I'm not sure what the difference between Level 1 #1 
"...operable through a keyboard" and Level 3 #1 "...designed to be 
operated by a keyboard..." I suspect it means add direct keyboard access 
via accesskeys for instance, but as a novice the two guidelines would 
sound the same... Also given the limitations of using accesskeys within 
various environments, "All functionality of the content...." may make it 
impossible to meet this requirement. Essentially only number keys are 
available for Web applications, so if a site had more than 10 functional 
features, it would fail this guideline. This is really a implementation 
issue devired from the HTML (and other) specification. The context of 
accesskeys needs to be defined in addition to the keys themselves. 
Context might be browser, web page, assistive technology, operating 
system etc.

Note that if Level 3 #1 is referring to direct keyboard access, via 
accesskeys for example, this criteria may conflict with 4.2 Level 1 #2h 
where the page in question is a screen in a web application.

Guideline 2.2
"Who benefits..." should include those with sensory disabilities as 
well, giving their assistive technology time to read through content 
before a time based event occurs. We tend to distinguish between 
physical disabilites that affect movement, and sensory disabilities that 
affect perception.

Guideline 2.3

How would an average person measure flash threshold? I'll wait for the 
TRACE utility in the second quarter of 2004

Level 3
General Flash Threshold #2 should be a range rather than an absolute 
value. For example an old real to real movie would flicker, but perhaps 
at a rate much faster than three flashes per second. More than about 20 
flashes per second (i.e. one flash every 50ms) can not be detected by 
most viewers  so at this rate the content would appear not to be 
flashing. Within what range does flashing actually induce seizures? 
Flicker rate between 3 flashes per second and 20 flashes per second 
should be listed as unacceptable.

Guideline 2.4

-#5 This whole guideline seems to be with regard to structuring of 
content to make it easy to navigate within larger content units. It 
might read better as "Facilitate the ability of users to orient 
themselves and move within the content by providing structural and 
orienting navigation elements" (e.g. paragraphs, headings, list etc and  
bypass links, return to top, jump to content etc.)

Level 2 #1 Why 50 and 50000? A 20000 word document would certainly be 
more accessible if it had a table of content.

How does a hierarchical structure differ from a table of contents or 
sitemap, which can both be heirarchical structures? A sitemap can take 
on linear, heirarchical, and global properties.

Don't know what Level 2 #1c means "... alternate display order ... or 
site navigation mechanisms. I'd guess it means allow users to rearrange 
the order in which they display pages so they could move through them in 
sequence, via a heirarchy, of in a global (non linear) manner.

Perhaps a level 1 criteria could suggest bypass links for more than 25 
navigation links. A great many site have 5 to ten navigation link across 
the top of the screen, and a subject menu down the left (sometimes 
right) of the screen that together can include 25 or many more links 
that have to be traversed through before reaching the relevant content. 
The Level 2 #2 guideline might be phrased as "... at the opening of, and 
within  pages, create direct links to major elements such as a content 
area, subject menu, or tool bar, that would allow users who might 
otherwise navigate through a screen in sequence, to bypass elements and 
jump directly to the relevant content ..."

Also in Level 2, would properly nested heading elements represent a 
heirarchical structure

Level 3
- if the default tab order is the logical sequence in which to read a 
document then additional information should not be required. Level 3 #1 
might be reworded using something like "Where the default tab order 
differs from the logical sequence in which a document should be read, 
provide information that describes the logical sequence"
- define "diagrams". Are they not usually images?  How would a screen 
reader user access the structure of a diagram. Perhaps it is possible, 
but I'm not familiar with such functionality. In most cases I would 
expect a long description of a diagram that outlines relationships 
between components in the diagram, or perhaps a caption, or text 
description in the surrounding content.
-#5b "...clear and informative titles" might be better as "...clear and 
informative headings"
-#5 "... a statement associated with the content..." might be better as 
".. a general statement about the content as a whole..." - a statement 
such as this with every page, as I interpret the current wording, seems 
to be overkill.

Guideline 3.1
- Level 1 #2 "meaning can programatically located" less technical 
language would make this easier to understand. such as "...meaning can 
be found by..." -- same for others in guideline 3.1. Programtically 
located or determined should refer to some form of machine evaluation, 
that can locate a full version of an  abbreviation etc. I understand 
that these word are probably used to suggest that evaluation tools can 
programmatically find alternatives for short forms, but I think 
terminology should explain accessibility for users rather than machines.

- Level 2 #1 when might "meaning and pronunciation" not be 
programatically locatable? When in an image perhaps, but that would be 
covered by 1.1
- Level 2 #2 perhaps a result of my confusion by the words 
"programtically determined", but in most case the meaning of idioms is 
determined from the surrounding language. I'd guess such meaning could 
not be programmatically determined. It would be "cool" if the meaning of 
cool could be programatically determined, but I think not.
- Level 2 #3 "...foreign language passage or phase..." would be more 
inclusive as "...foreign language passage or words..". The word phrase 
could be interpreted as excluding single words.
-Level 3 #1 I see no need to include a word's definition if it is not 
the primary or first meaning expressed in a dictionary (whose 
dictionary?). Meaning is such cases is usually determine from the 
surrounding words. How would an evaluation tool determine if the primary 
meaning was being used.
-Level 3 #2 "... read by themselves as a group" sounds like an oxymoron. 
perhasp" Section headings and link text are understandable when read 
individually, or read as part of a group
-Level 3 #3 should not be an accessibility guideline. Whole disiplines 
are devoted to good writing, and wrting should not be under the realm of 
accessibility. I can imagine a very large corporate site, with large 
amounts of content, that is seeking a Level 3 conformance review. Having 
to review the language used throughout the site would probably triple 
the cost of an evaluation having to read an analyze content. It would 
require expert knowledge of language usr by the evaluator, knowledge of 
the site's audience, knowledge of content area specific language.... 
Copy editors do this kind of work, rather than accessibility evaluators. 
I'm also having a hard time imagining how a accessibility evaluation 
tool might evaluate language usage, for various audiences, or across 
various genres.

Guideline 3.2
Level 2 #5 should be "Explicit notice is given in advance, or 
immediately following any extreme change of context". While it is 
preferable to warn users ahead of time that an extreme change is about 
to occur, it is not always practical to do so. In some instances it is 
more effective to inform the user after the change. For example, a 
collection of context sensitive help windows are found throughout an 
application that open by clicking a "Help" link next to particular 
features. An author could include a general statement on each page about 
help links that informs the user that they open in a new window, but 
such a statement may go unnoticed, and would add clutter. Title text 
could be included with links etc that states that a link opens in a new 
window. This could potentially create large amounts of repetetive text 
for those listening to pages, and potentially bloat the source code. The 
best method we have found in cases like this is to consistently include 
a "close this window" link/button as the first feature in a newly opened 
window. When used consistently this method informs the users of an 
extreme change after it has occured.

We also use consistent feedback after an extreme change to inform a user 
of an outcome of a particular action. For example, after saving content 
being authored in a web based authoring tool, the editor utility closes 
and users is redirected to the actual display of the content, which 
includes a notice stating the outcome of the save content action. It 
would be impratical to inform users on the editor screen that when they 
save their content they will be redirected to the display screen. There 
are many other similar action (e.g posting a forum message, filling out 
a registration form, logging in) that result is extreme changes in 
context that are better describe after the change has occured. Though 
there are many cases when users should be informed before a change 
occurs, there are also many instances when it is more effective to 
announce the change after it has occured. Authors should not be 
penalized for using the latter a strategy.

Level 2 #6 Good. So "click here" is acceptable as link text provide its 
meaning can be determined through the surrounding context, such as a 
linked article title appearing before the click here link.

Guideline 4.1
Level 1 #1a Could be hard to enforce. How would an evaluator determine 
if Javascript has been used to spec? Whether pdf, flash, java has been 
used to spec? If Java is used to spec but without SWING, it would pass 
but not be accessible. If Flash MX presentation is used without the 
accessibility features, it would pass but be innaccessible. A third 
criteria might be added that requires authors to use accessibility 
features within a specification where they exists:
"1c. accessibility feature provided in a specification are used." This 
might be a Level 2 criteria. I see this guideline listed as a level 2 
for guideline 4.2. I might argue that it fits better in the "use to 
specification" guideline.

Guideline 4.2
There should be some form of limitation associated with this guideline. 
For example, SWING enabled applets may be accessible to users of current 
versions of JAWS, but would not be accessible to those using a two year 
old version of JAWS. Same for PDF tagging, and Flash MX accesibility 
extensions. If the intent is to create content that is accessible to 
current technologies, as describe in design principle 4, this guideline 
might read

"4.2 Ensure that user interface features are accessible to current 
technologies, or provide an accessible alternative."

That said, a "current technology" limitation is somewhat counter to the 
philosophy behind WCAG 1.0 which was to extend accessibility to include 
those of older technology (ala "Until User Agents...") I don't have an 
answer to what consititutes a reasonable limitation on legacy AT 
support, but it should receive some attention so authors have a concrete 
defintion to work from.

This guideline somewhat precludes accessibility to Lynx users. For 
example a Flash presentation may now be accessible to an IE6/JAWS 4.5, 
but would not be accessible to a Lynx/JAWS4.5 user. A limitation in this 
respect might read:

Level 1 #3 When a UAAG conformant plugin, or application is not readily 
available, provide an accessible alternative to the content"
Documenting technology requirements is a good step toward placing 
limitations on technology/legacy support. Readiliy available might be 
confirmed by an author providing a link to such a plugin/application. 
Should "freely available" be included in this criteria?

Level 1 #2h Although I agree, item 2h is going to generate resistance, 
given the current arguments over the implementation of accesskeys. In 
this case what used to be a Priority 3 checkpoint, is now a level one 
when it applies to a Web application. Are there plans to improve upon 
accesskey implementation in UAAG, XHTML,WCAG. For example defining 
contexts for accesskeys so HTML defined accesskeys do not conflict with 
UA accesskeys. This may be less relevant for most Web site, but will be 
highly relevant for Web applications.
Received on Tuesday, 7 September 2004 21:44:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:37 UTC