W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > July 2005

Comments on WCAG2 Draft June 30/05

From: Greg Gay <g.gay@utoronto.ca>
Date: Thu, 28 Jul 2005 11:25:12 -0400
Message-ID: <42E8F8D8.9000106@utoronto.ca>
To: public-comments-wcag20@w3.org
CC: Greg Gay <g.gay@utoronto.ca>, Wendy A Chisholm <wendy@w3.org>, Chris Ridpath <chris.ridpath@utoronto.ca>

July 28,05
WCAG 2.0 Comments  on Draft June 30/05

1. ...should WCAG 2.0 have 2 or 3 levels of conformance?

There are many reasons why a three level conformance framework should be 

For a transition from WCAG 1.0 to WCAG 2.0  that will be easy to 
comprehend for content developers, evaluators, and clients who are 
currently accustomed to the "required, should, could" notions that give 
concrete meaning to priority levels, a three level structure should be 
used using similar or the same associated meanings. There are still 
things that "must" be done or content  will be inaccessible to a 
particular group. There are things that "should" be done, or some groups 
are going to have a difficult time accessing content, but where 
accessing content is otherwise possible. There are things that "could" 
be done to improve usability beyond what might be considered technically 

There are cases in the WCAG 2 draft where current level 3 success 
criteria are relatively difficult or unnecessary to implement, and as a 
result would prevent many sites from conforming with Level 2 guidelines 
should the guidelines be moved from level 3 to level 2. For  example, 
guideline 3.1 Level 3 #1 "A Mechanism is available for finding 
definitions for all words..." is not something most sites would 
implement. A glossary is more likely to be implemented for specific 
keywords, though still relatively rare, but for definitions for all 
words a full dictionary would need to be available. Very few site would 
thus be able to comply with level 2. If a person needs a dictionary 
there are many such sites available on the Internet. There is no reason 
why every site that wishes to comply with Level 2 guidelines has to have 
their own dictionary. I don't think requiring a dictionary should be a 
requirement at any level.

Likewise, if a site is specifically targeting post secondary students or 
a professional audience,  providing a summary, graphic, or spoken 
version at a lower education level is generally unnecessary (re: 
guideline 3.1 Level 3 #5). As a result such a level 2 requirement would 
prevent most post secondary sites from attaining Level 2 conformance. 
The audience being addressed might be included in the baseline, and this 
guideline adjusted to reflect accommodations for that particular 
audience, rather than an outright requirement that all content needs to 
be readable by all, or have a summary with primary level language.

I'd vote for sticking with the meanings currently associated with 
priority levels of WCAG 1.0, and go with three levels of success 
criteria in WCAG 2.0. Grouping all current level 2 and level 3 
guidelines into one level is going to blur the importance of the current 
level 2 guidelines. It will discourage content developers from 
attempting to go beyond the basic accessibility of level 1, if level 2 
is generally unattainable for average content developers.

2. Should a validity success criterion be addressed at Level 1 or Level 
2 (refer to "Validity and Accessibility" for a summary of recent 

While I certainly think validity is a reflection of quality, and in all 
our work validation is a key step in our development process, I tend to 
agree that it should not be the responsibility of the WCAG to police the 
validation of Web documents. Though intended as recommendations, as 
noted, WCAG does end up being the basis for policy, and a requirement 
for valid markup is going to have serious legal and financial 
consequences for those bound by policies based on WCAG.

When we evaluate Web sites virtually all fail the validity check. 
Sometimes they might fail by simple omission or perhaps a  typo or two, 
such as  the odd broken tag on a few pages within a larger site. Other 
times sites are a mess with broken markup throughout. In the latter case 
there will likely be accessibility problems as a result of the invalid 
markup, but in the former the minor markup errors will likely have no 
affect at all. There is no clear line between validity that affects 
accessibility, and validity that does not. WCAG's primary concern should 
only be with validity issues that do affect accessibility, not with 
validity in general.

If validity is to be a Level 1 success criteria, a distinction would 
have to be made between markup errors that are proven to be 
accessibility barriers (these will differ across user agents, and will 
change over time), and errors that do not affect accessibility. How one 
would go about making the distinction I do not know. Given individual 
errors may not cause accessibility problems, but combinations of errors 
often do, documenting Level 1 and Level 2 validation errors would likely 
not be possible without a major effort. Then checking for those errors, 
or combinations thereof, is also going to be difficult to accomplish.

If the validity requirement is made a Level 1  criteria, it will be the 
single most difficult hurdle to conformance, and given that in most 
cases where invalid markup is encountered there is no affect on 
accessibility, making a general requirement that all markup be valid 
would be problematic This would be particularly true for dynamic sites 
where information changes regularly or where user contributed 
information is collected. As a Level 2 requirement, at least these sites 
could claim a consistent level 1 conformance. They may never be able to 
claim conformance if validity is listed as a level 1  requirement.

My vote is to leave validation a Level 2 success criteria, though within 
a three level (required, should, could) conformance framework.

Baseline!!! Great idea! Audience needs to be added to the baseline in 
addition to technologies. See below re: guideline 3.1 Level 3 #5, 
particularly important if level 3 guidelines are merged with level 2.

1. Technology assumptions and the baseline

I realize these two examples are informative, but they have the 
potential to create confusion through multiple interpretations.

Example 2 "...supported by more than one accessible and affordable user 
agent for more than one release."  The word release is a relative term. 
Release cycles vary greatly for different software. Does this include 
major and/or minor releases (e.g. feature release vs a bug fix release). 
What about where only one accessible user agent exists, like Internet 
Explorer was for the longest time. Use words like "readily available 
user agent" rather than "more than one."  The words "readily available" 
could also remove multiple interpretation of the word "release". A 
definition of the phrase "readily available" could be added to the 
glossary, with a definition something like "...with minimal effort  is 
attainable by searching the Internet."

Example 3 "... to reflect the increased ability of affordable user agent 
(including assistive technology)..." I might ask "are there affordable 
assistive technologies?" thinking about the current cost of screen 
readers. The affordability of assistive technologies is  relative to a 
person's income, or the availability of funding to them (in Canada  
funding is available every five years), so this leaves room for many 
different interpretations.  Perhaps replace "affordable" with "readily 

Conformance Claims
Regarding #2 of the information that must be included with a conformance 
claim, "... a list of one or more URIs ...". In the case of a Web 
application, a base URI may not be available. For example, our Web 
applications claim AA conformance, but they do not reside at any 
specific URI, but rather at many URIs where users have installed the 
software, or at open source repositories that distribute the software. 
The applications exist as archived bundles of  software, that when 
unpacked  and installed on a user's Web site, will conform with WCAG AA 

Or, could the URI perhaps be a download location of the primary software 
distribution. Perhaps yes, but this did not seem immediately apparent 
when I read it the first time (thinking to myself aloud). The definition 
of  "delivery unit" might include mention of a "software package" or 
"software archive". A Web application distributed by CD may not have an 
associated URI at all, but may otherwise be conformant. The #2 
requirement should also include something like "...or a software version 
identifier where a URI is not available."

Also with regard to conformance claims, a date on which the claim was 
made should also be included.  For Web sites that are continually 
changing, the accessibility of the site may vary from day to day. For 
the protection of human evaluators who find a site to be conformant, 
then are brought to task a month later, for example, when the evolving 
site is found to no longer conform, a "date of conformance" is required. 
The only case where a conformance claim remains valid indefinitely, 
which would be assumed if no date were specified, is when the content of 
a web site does not change (which relatively is rare).

Similarly a claim of conformance could be made on one version of a Web 
application, and be carried over to later versions of the software, 
which are perhaps not conformant if a date of conformance or software 
version identifier is not associated with the claim.

Principle 1:
Level 1 Success Criteria for Guideline 1.1
While I do believe all meaningless non-text elements should have a text 
alternative, success criteria 1.1 #4 is not a critical accessibility 
issue, and thus does not warrant a level 1 rating. If the image does not 
convey meaning, assistive technologies announcing the filename disrupts 
comprehension of the page being read, but it does not prevent a user 
from accessing the content of the page as would a missing text 
alternative  for non-text content that does contain meaningful 
information. Perhaps include this item as a level 2 success criteria 
which is describe as a "should" do item to make it less difficult to 
access the content in question.

Guideline 1.2
1.a A text transcript should be required at level 1 to accommodate those 
using technology that does not read the captions in a particular user agent.
1.b I agree that adding captioning is effortful, and may ultimately be 
seen as "undue hardship" in the eyes of the courts, and thus be ignored 
altogether. If the transcript is required at level 1, there will always 
be a text alternative. Given transcripts are fairly easy to create, 
undue hardship could never be a defense for not include a text alternative.

There could also be reference to "readily available" for the above with 
regard to captioning software, in which case it may be more reasonable 
to leave captioning as a level 1 success criteria.

2. Audio descriptions may also fall under the "undue hardship" category 
if maintained as a level 1 success criteria. Also, there is a question 
of subjectivity in what requires an audio description, and the capacity 
to include audio descriptions where the video does not have sufficient 
breaks into which it can be inserted. Including a text version of the 
audio descriptions as part of a transcript as mentioned for 1a above as 
a level 1 criteria,  would assure that an alternative exists in some form.

*While I think of the "undue hardship" clause as a poor defense in most 
cases, if the effort required to add synchronized captioning and 
descriptive audio (particularly descriptive audio, and extended audio 
descriptions) approaches a significant cost within the overall cost of 
producing the video, courts are likely to favor the undue hardship 
argument. Captioning and descriptive audio as level 2 items, and 
transcripts of audio and video tracks as level 1, would remove the undue 
hardship defense.*

Guideline 1.3
The association between guideline 1.3 and its examples is not 
immediately apparent. While each example represents some implementation 
of structure, how they represent separation from presentation is not 
clear.  Example #2 re associating table headers with data cells might 
fit better into Guideline 2.4, where structure is more thoroughly covered.

Guideline 1.4
Guideline 1.4 does not seem general enough, specifying images or sound, 
but not colour (though colour is mentioned is the level 1 success 
criteria). (i.e. "Make it easy to distinguish foreground information 
from background images or sounds)." Perhaps the words "images or sounds" 
should be replaced with "information" to make the guideline more general.

Level 1 success criteria for guideline 1.4 seems a little weak, though 
unless the algorithm of level 2 #1, to measure contrast between 
foreground and background colours, comes about before the release of 
WCAG 2, there's probably nothing better than "programmatically 
determined" colours so users agents can make adjustments as required. 
The problem is colours can be programmatically determine with relative 
ease in most cases, but there is no mention of contrast between 
foreground and background colours in level 1. Presenting bright yellow 
on a white background for example, would not violate this guideline if 
the colours were explicitly defined as an attribute or style, but the 
text would be inaccessible to most people who are not using an assistive 
technology that reads colour attributes;   essentially disabling 
otherwise fully able users.

Perhaps it would be more effective here to "...ensure that foreground 
and background colours can be overridden by the reader," which is 
perhaps what "programmatically determined" means in this case.  Perhaps 
include an example for Guideline 1.4 that describes the ability to 
override presentation styles would add clarity to the level 1 criteria, 
and an example of foreground background readability (or non-readability 
as the case may be).

Principle 2
Guideline 2.4
Level 2 Success Criteria #1.
Similar to the timed content 2.2 Level #1 guideline  "...without 
invalidating the activity" could be used here as well, with reference to 
providing alternate paths for navigating content. For example "More than 
one way is available to locate content within a set of delivery units 
except where non-sequential navigation would change the intended outcome 
of an activity".

2.4 Level 2 #2  might also include reference to bypassing large blocks 
of data (i.e. data tables). Similarly, things like an alphabetized 
browse menu for a glossary can use bypass links. These might be better 
referred to in examples.

2.4 ... who benefits.
It's not clear to me what the following means in the Who Benefits 
section of guideline 2.4: "Individuals with cognitive disabilities may 
find it easier to ask for what they want than to deduce its location 
from categorical choices." particularly the word "ask" as it relates to 
mechanisms to find, orient, and navigate Web content. Structures like 
headings for example, are more apt to draw users with cognitive 
disabilities to categorical information that aids in comprehension, like 
that described for blind users above "... jumping from header to header 
to get an overview or to more quickly skim...". Most people, including 
those with cognitive disabilities, can benefit from the summary 
information structures provide, for comprehension and learning.

Principle 3

In Who benefits from Guideline 3.2, reference to difficulty interpreting 
visual cues here, and in the Who benefits section for 3.1, are only 
remotely representative of dyslexics. Dyslexia is specifically 
associated with difficulties making letter to sound correspondences 
(i.e. phonemic awareness). With regard to having difficulty interpreting 
visual cues, WCAG should perhaps refer to dyspraxia, or better to  
non-verbal learning disability. Though not specifically associated with 
difficulties interpreting visual cues, these latter disabilities are 
more likely to include them. Dyslexics as a group tend to be good at 
interpreting visual cues, with visual difficulties occurring only when 
multiple disabilities are present.

For guideline 3.1 a Level 2 success criteria might be added to suggest 
using meaningful link text (i.e. navigation controls), or provide 
context that allows users to infer meaning where the link text is 
otherwise meaningless. In the latter case for example, a link to a full 
article via its title, followed by a link with the link text "more" 
provides context for the otherwise meaningless word "more." This is 
likely HTML specific so it might fit as an example for a more general 
requirement the interface controls be meaningful.

Principle 4
Guideline 4.2 Level 1 item 1 suggests that alternatives are preferable 
over making the original Web content accessible in the first place. 
Rather than "If content does not meet all level 1 success criteria..." 
use "If content can not be authored to meet all level 1 success criteria..."

Guideline 4.2 Who benefits, the first statement and its list items seem 
redundant. The statement might read better as "Authors who address 
accessibility during the design stage of content development, 
will:"...to distinguish between designing for accessibility and 
retrofitting for accessibility.

Guideline 4.2 Use of relative measures should be a level 2 success 
criteria. There might include an example that mentions relative measure 
for defining layout and font sizing. If fonts must be marked up in a way 
that allows them to be increased in size  for those with low vision, the 
layout elements must also be included in this requirement so as the font 
size increases, the surrounding containers also increase in size, so one 
does not end up with a paragraph displayed as a single column of words 
for  example. Similarly, relative sizing could be used to define image 
sizes (16px = 1 em) so images also increase in size relative to the 
fonts and their containers, and the symmetry of the screen is maintained.
Received on Thursday, 28 July 2005 15:31:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:05 UTC