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

Comments on Level 1 Success Criteria by Don Barrett

From: Don <donter@verizon.net>
Date: Thu, 15 Dec 2005 13:22:02 -0500
To: <public-comments-wcag20@w3.org>
Message-id: <000001c601a4$72c7aa30$6400a8c0@donbarrett>

Although I realize it is somewhat late in the game, I have taken a very hard
and thoughtful look at part of the proposed WCAG 2.0 standards.  As someone
who has worked for years as a Section 508 tester, working closely with
developers with tight deadlines, customers with limited time and funds, I
believe I bring a special perspective to viewing the standards as they
currently exist.

Let me be clear that although I am well versed in the relationship between
the WCAG 1.0 and the Section 508 standards, my comments are not related to
any discussion of the new WCAG standards as they relate to 508 except for
one major issue.  There is absolutely no doubt that the Access Board is
looking seriously at the Success Criteria as they are being formulated, and
that these criteria, like the guidelines before them, will have a profound
and lasting impact upon the creation of the revised 508 standards as they
will be conceived.

This means that your responsibilities are weighty and awesome in light of
the fact that no doubt that much of the work you are now conceiving could
easily become Federal law in a matter of a few short years.

It is critical then, that to the utmost degree, the Success Criteria are
able to stand on their own, are clear, concise, easy to use, and speak to a
wide audience.  To the extent they can do these things, and to the extent
they exemplify with crystal clarity the current state of knowledge in
forming the basis of accessible design, to that extent they will continue to
drive the development of the new standards, the revision of which was
recently approved by the full Access Board.

Thus, I deliberately have looked only at the Success Criteria, and have, by
choice, not read the supporting standards document with all of its
explanatory material.  I am sure that there are those among you who will
immediately dismiss this tactic as ill-advised and unfair, since I am
deliberately not taking the whole of the proposed standards in their
totality, but only a small portion thereof.

I have chosen this strategy, as it is my intent to mimic the manner in which
these criteria will be used in the real world by stressed and harried
development teams if they are adopted, as we are hoping they will be, by the
Committees which will be working on the new 508.

But whether or not this happens, like the 508 standards, the Level 1 Success
Criteria will be read by most developers by themselves, and must therefore
stand on their own merit for being crystal clear and useable as coding
decisions are being made.  It has been our experience that most developers
with whom we work have very little time to become familiar with the
rationale, history, and nature of the standards they are intending to meet,
and simply want the bare necessities provided them in the form of quick do's
and don'ts.  In our real-world testing scenarios in which we are involved,
most of the time, it is the 508 standards, and the 508 standards alone,
which the developers seek to understand as they neither have the time or the
inclination to delve deeply into their ideology. 

Most of the development teams with whom we have worked rely upon our
assistive technology program staff to quickly and simply explain what we
want and what is meant by accessible design so they in turn can work as
quickly as possible do code to our requirements.  To those without
disabilities who also have no knowledge of the topic, the whole concept of
accessible design, though laudable, is esoteric and at times difficult to

Therefore, the Level 1 Success Criteria, I believe, should be able to stand
alone on their own merit, providing the kinds of instructions, insights, and
guidance which will mark them as standards worthy of emulation by the 508
team to come.  Those phrases, terms, and concepts which are muddy, arcane,
jargonesque, and without relevance should be removed, examples provided
where necessary, and concepts embellished as appropriate.

As an individual who has met with literally hundreds of developers over the
past few years, explaining ad nauseam such concepts as functional text,
repetitive links, frame navigation, etc., I can tell you without a doubt
that your mission is clear - to make what is so well-known to you clear to
those for whom it is totally unknown. 

Before I begin commenting on each of the SC, I recognize that you are all
doing this as dedicated, hard-working, and deeply caring volunteers, for
whom accessibility is a mission and a life's commitment.  As one who is both
a tester of sites, and an avid user as well, I want to express my sincere
gratitude for all of your efforts, which directly and personally benefit me
and countless numbers of other blind individuals throughout the world.  My
comments therefore, are in no way meant to criticize, but rather to
stimulate discussion so that, perhaps, your efforts will yield additional

Don Barrett

(Comments appear below most of the Success Criteria (SC) and begin with

1.1.1  For non-text content that is used to convey information, text
alternatives identify the non-text content and convey the same information.
For multimedia, provide a text-alternative that identifies the multimedia.

Don:  Instead of identify, consider replicate.  Identify is somewhat
confusing, in that identifying non-text content or multimedia doesn't at all
imply comparable access, but merely calls attention to its existence.

1.1.2  For non-text content that is functional, text alternatives serve the
same purpose as the non-text content.  If text alternatives can not serve
the same purpose as the functional non-text content, text alternatives
identify the purpose of the functional non-text content.

Don:  The phrase "serve the same purpose" might work well in 1.1.1 instead
of identify.

1.1.3  For non-text content that is intended to create a specific sensory
experience, text alternatives at least identify the non-text content with a
descriptive label.

Don:  Consider adding the word "only" before the word "intended."  This
shows that in the hierarchy of importance, a sensory experience is less
critical than function or information.

1.1.4  Non-text content that is not functional, is not used to convey
information, and does not create a specific sensory experience is
implemented such that it can be ignored by assistive technology.

Don:  Here, an example would be perfect after the word "technology," as in
"such as in alt=" ".  As written now, not one developer I know will know how
to implement this since none of them know what assistive technology will and
will not ignore.

1.1.5  For live audio-only or live video-only content, text alternatives at
least identify the purpose of the content with a descriptive label.

1.2.1  Captions are provided for prerecorded multimedia.

1.2.2  Audio descriptions of video are provided for prerecorded multimedia.

Don:  This should be qualified so that the provision of audio description
does not appear to be as equally important as captions.  Any blind person
who believes that audio description is as important as captioning in all
cases is na´ve and inexperienced.  I have yet to see a Federal site with
visual material that required the addition of audio description for
accessibility purposes only, yet any with dialog must be captioned.

1.3.1  Perceivable structures within the content can be programmatically

Don:  This is not clear, not easy to use, and not at all written to a
diverse audience.  First, please consider replacing the phrase
"Programmatically determined" with its definition.  Thus, after the word
Structures," "can be recognized by user agents, including assistive
technologies, that support the technologies "in use" instead of "in the
chosen baseline."

Jargonesque terms such as "programmatically determined," "chosen baseline,"
and my favorite cringer, "delivery unit" stand out not as bastions of
clarity, but rather as arcane, obscure, and unfamiliar.  Jargon has its
place among professionals as all of you know, and people have the right to
use jargon to speak to those select few who have mastered a profession and
gained the respect of their colleagues, but such terms are out of place
here.  Remember, your brilliance and wisdom as authors is not captured by
your use of jargon, but rather by the simplicity, clarity, and profundity of
the standards themselves.

Also, I think it potentially problematic to lump assistive technology in
with other user agents.  You are basically telling developers that they
can't use any code which can't be parsed by assistive technology, which as a
whole, is much more limited than other user agents in its ability to respond
to various code types and structures.  Given the current and future
proliferation of new web technologies, we should be pushing AT developers to
broaden the code their products can handle, rather than trying to force
developers to limit their use of these new technologies.

Perhaps "including assistive technologies" might be changed to something
like "and is/are made available to assistive technologies."

1.3.2  When information is conveyed by color, the color can be
programmatically determined or the information is also conveyed through
another means that does not depend on the user's ability to differentiate

Don: Please here as well, expand "programmatically determined" to state the
concepts contained in its definition which are readily understandable.

2.1.1  All functionality of the content is operable in a non time-dependent
manner through a keyboard interface, except where the task requires analog,
time-dependent input.

Don:  I don't know a developer in the world who will automatically just
"know" what the phrase "where the task requires analog, time-dependent
input" means.  This cries out for an example.  Please remember -- diverse

2.2.1  For each time-out that is a function of the content, at least one of
the following is true:
* The user is allowed to deactivate the time-out, or;
* the user is allowed to adjust the time-out over a wide range which is at
least ten times the length of the default setting, or;
* the user is warned before time expires and given at least 20 seconds to
extend the time-out with a simple action (for example, "hit any key") and
the user is allowed to extend the timeout at least 10 times, or;
* the time-out is an important part of a real-time event (for example, an
auction), and no alternative to the time-out is possible, or;
* the time-out is part of an activity where timing is essential (for
example, competitive gaming or time-based testing) and time limits can not
be extended further without invalidating the activity. 

Don:  This is my favorite Success Criterion, not because I have any affinity
for timed responses, but because it is spelled out clearly and its breadth
and scope are explained.  Yes, it is long, but it is well thought out, makes
sense, and is eminently practical.

2.3.1  When content violates either the general flash threshold or the red
flash threshold, users are warned in a way that they can avoid it.

2.4.1  Navigational features within the content can be programmatically

2.5.1  If an input error is detected, the error is identified and described
to the user in text.

Don:  Yes, genius without jargon; beautiful!!!!!

3.1.1  The primary natural language or languages of the delivery unit can be
programmatically determined.

Don:  Well, you know what I think of "delivery unit;" why not "displayed
content."  DU just sounds so silly and out of place.

3.2.1  When any component receives focus, it does not cause a change of

Don:  Hmmmm, hard to understand.  I would rather see after "cause" "an
inappropriate change of content."  From my experience, it's the inadvertent
or inappropriate content changes when focus is moved which causes real
problems.  I am not sure how the other definitions of change of context
apply here.  I may be missing something.

4.1.1  Delivery units can be parsed unambiguously and the relationships in
the resulting data structure are also unambiguous.

Don:  God help us!!  English please; I am sure I've seen this violated
somewhere, but I don't even know what it means.  Please, fix it or junk it.

4.2.1  If content does not meet all level 1 success criteria, then an
alternate version is available from the same URI that does meet all level 1
success criteria.

Don:  Yes, great!

4.2.2  Content meets the following criteria even if the content uses a
technology that is not in the chosen baseline:
1. When content violates either the general flash threshold or the red flash
threshold, users are warned in a way that they can avoid it. 
2. If the user can enter the content using the keyboard, then the user can
exit the content using the keyboard. 

Don:  Is the phrase which begins "even if" necessary?  It should end with

4.2.3  The role, state, and value can be programmatically determined for
every user interface component of the web content that accepts input from
the user or changes dynamically in response to user input or external

Don:  Yes, yes, yes!!

4.2.4  The label of each user interface control that accepts input from the
user can be programmatically determined and is explicitly associated with
the control.

Don:  Jargon aside, great!!!!

4.2.5 The content and properties of user interface elements that can be
changed via the user interface can also be directly changed

Don:  Sounds terrific, but what does it really mean to a coder; why is it
relevant; how does it help accessibility; examples please!!!!

4.2.6 Changes to content, structure, selection, focus, attributes, values,
state, and relationships can be programmatically determined.

Don:  After fleshing out and changing the definition of "programmatically
determined," the standard might now read "Changes to content, structure,
selection, focus, attributes, values, state, and relationships can be
recognized by user agents and are made available to assistive technologies."
Please consider reworking all of the standards which contain the phrase
"programmatically determined" to reflect this or similar changes.

-- End of Comments
Received on Friday, 16 December 2005 12:19:55 UTC

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