Share this on

Translations

Job Board

A new revision of the guidelines, WCAG 2.0, is being written. The
development process is going slowly and is in danger of
recapitulating many of the errors of WCAG 1.0 — unrealistic
guidelines divorced from real-world web development that are at once
too vague and too specific.

But you, the indie developer, can help prevent this tragedy by
investing a small period of time in one of a few limited areas that
may interest you. Instead of working on the entire WCAG, we need you
to focus on topics in which you may have expertise or experience. By
participating in this limited way, you can help save web
accessibility from itself.

Enlightened self-interest

If you choose to make standards-compliant websites, inevitably you
will have to follow the guidelines. It’s foreseeable that you
could be legally required to follow WCAG 2.0. You could opt into
following the guidelines or they could be foisted upon you.

You thus have an enlightened self-interest in ensuring the new
guidelines actually make sense. Moreover, we simply need more
contributors.

The participation problem

I’ve been posting to the W3C’s accessibility-related
mailing lists since 1999 and I still
haven’t figured out how the WAI works. You don’t need to,
either.

You just need to know that the two main mailing lists for WAI discussions are:

Not surprisingly, more people are interested in WAI-IG’s
general chitchat than WAI-GL’s topic-specific discussions. From
June 2002 to June 2003, 290 different people posted to WAI-IG, but
fewer than half as many (114) posted to WAI-GL.

That sounds like a lot, but it isn’t. Web development now
ranges widely, with many overlapping fields of expertise. WCAG 2.0
will impinge on many of those fields, including page structure (XHTML
and similar markup languages), CSS, multimedia, usability,
information architecture, writing, and myriad disability-specific
issues. I know for a fact that leading experts in several web topics
unrelated to disability, whose names would be immediately recognized
by au courant indie developers, simply do not
post to either mailing list. We have no evidence that actual experts
in many pertinent fields are part of the development process for WCAG
2.0.

And it shows. The current drafts of WCAG 2.0 are a marked and
indisputable improvement over the antediluvian WCAG 1.0, but they
still have far too little bearing on the real world of the web.

This is where you come in.

Bite-size pieces

At press time, the current draft of WCAG 2.0 was 14,000 words long
without markup. I don’t see how anybody could tackle something
that big in one sitting. It’s like an anaconda trying to
swallow a Range Rover.

What I’ve done, then, is to break up the WCAG draft into
“action items,” as the business types say. The themes I
have chosen are:

Deficiency report

Before everyone starts accusing me of being “too
critical,” which is like accusing the sky of being too blue,
understand that this article is a deficiency report on WCAG
2.0. We can’t afford to pretend to be more positive, upbeat,
and complimentary than is justified by the actual guidelines. We have
only a short window of opportunity to fix what’s wrong, and we
can’t do that without identifying what’s wrong. This
is no time to accentuate the positive.

The approach here is similar to engineering documentation, where
succeeding drafts produce deficiency reports, each of whose items is
either corrected, ruled not to be a deficiency, or simply lived with
until the next draft. The process recurs until collaborators have
corrected or decided to live with every error.

(I have separately written two briefing documents for a previous
face-to-face WCAG meeting that list deficiencies and recommendations, if anyone is interested.)

Where to find the originals

The documents don’t use enough fragment identifiers. You
can’t link directly to enough sections and paragraphs. Where
there’s a link, I’ll give it, but a lot of the time
you’re going to be stuck using the Find command in your
browser. Moreover, in subsequent drafts, wording is guaranteed to
change.

Action items

Rewrite

These guidelines need rewriting and clarification. But the problem is
much worse than that: The entirety of WCAG 2.0 is a
poorly-written morass. The document violates its own draft guidelines
on clear and simple writing. It is an outright mess, and urgent
plain-English rewrites are required. The Web Accessibility
Initiative, which has a budget, should hire professional
plain-English consultants for this task. It’s time to end the
W3C’s tradition of incomprehensible documents.

Still, for the purposes of this section, we’ll focus on
sections that make next to no sense as written.

All non-text content that can be expressed in words has a text
equivalent of the function or information that the non-text content
was intended to convey.

Non-text content that can be expressed in
words has a text equivalent explicitly associated with it.

Non-text content that cannot be expressed
in words has a descriptive label provided as its text equivalent.

The text equivalent should fulfill the
same function as the author intended for the non-text content (i.e.,
it presents all of the intended information and/or achieves the same
function of the non-text content).

WAI’s warning against the use of illustrations: If this
guideline even deserves to be included, it requires rewording.

Designers need to be cautious in deciding when to use
illustrations. Reading a picture is probably a learned activity that
is easier for some than others. Some users skip the pictures; others
read only the pictures. Designers must also recognize that visual
conventions are not universal and that individuals develop their own
mental schema and expectations in interpreting visual information.

Retransmitted captioning and audio description: Can you understand
this guideline?

If content is rebroadcast from another medium or
resource that complies to broadcast requirements for accessibility
(independent of these guidelines), the rebroadcast satisfies the
checkpoint if it complies with the other guidelines.

Presentation is the rendering of
the content and structure in a form that can be sensed by the user.

structure

Structure includes both
hierarchical structure of the content and non-hierarchical
relationships such as cross-references, or the correspondence between
header and data cells in a table.

Examples

In this section, these guidelines require more examples. Here is
where my readers can do the most good with the least effort: All we
need, in most of these sections, are a few people’s
contributions of one or two examples each of real-world sites. The
sites you suggest could fully meet, partially meet, or entirely fail
the proposed guideline.

You can also recount your own lived experiences as a web user.

The important thing here is to get WAI out of its habit of
half-arsed hypothesizing. We want their guidelines applied against
existing sites of all descriptions. WAI is not interested in finding
those sites on its own, so we have to hand the facts to them on a
platter.

Yet
more text equivalents. WAI just can’t get enough of those.
But we need a wider range of actual examples of text equivalents in
real use today, whether well-done or not.

Non-text content that can be expressed in
words has a text equivalent explicitly associated with it.

Non-text content that cannot be expressed
in words has a descriptive label provided as its text equivalent.

The text equivalent should fulfill the
same function as the author intended for the non-text content (i.e.,
it presents all of the intended information and/or achieves the same
function of the non-text content).

WAI dabbles dangerously in the issue of writing, a topic about which
it has a demonstrable lack of expertise. Its concern
with “concrete concepts” and similar classifications of
the written word is meant to assist people with learning
disabilities, but little good will come of it unless we know exactly
what they’re talking about. Do you?

Example 1: A description of a
process.

A page describes how to learn to play soccer. Each
step in learning the fundamentals of the game is illustrated with a
photograph of a player doing what is described in the text.

Example 2: A concrete
concept.

The primary concept on a page is concrete. It is
discussing Mt. Pinatubo. It includes both a description of the 1991
eruption as well as photos of the eruption and the aftermath. It
links to another site that contains video and another site that
contains a 3D simulation of what happened underneath the crust and
within the volcano during the eruption.

Example 3: Child’s report of school trip.

A child went with her school on a trip to a
bicycle manufacturing plant. She wrote a report for her family and
friends to post to the web. In the report, she includes the company
logo as well as a picture of a bicycle on the assembly line. She
links to the company website for more information. She includes
photos she took of the plant.

Example 4: Stock-trading
data.

A news site is comparing the performance of the
economy from third quarter of this year with third quarter from the
last three years. They compare prices of the most popular stocks.
They present the data in a bar graph with a link to the raw data they
used to create the bar graph.

Example 5: History of music.

A grandfather’s hobby is listening to and
playing music. He creates a website that includes examples of many
different types of music and musical instruments. When describing
specific types of music, he links to a short sound clip.

Benefits
of accessible alternatives need a few case studies (which, oddly, WAI
could crib from its own page).

Individuals who are blind, have low vision, have
cognitive disabilities or have trouble reading text for any reason
can have the text read aloud to them.

Individuals who are deaf, are hard of hearing or
who are having trouble understanding the audio information for any
reason can read the text presentation or have it translated and
presented as sign language by their assistive technology.

Individuals who are blind or deaf-blind can have
the information presented in Braille.

Examples
of multimedia accessibility: I know I’m not the only one
who actually watches captioning and audio description. I know that
few involved in WAI do. Real-life experiences and examples are called
for here.

Example 1: A movie clip with audio
description and captions.

A clip from a movie is published on a website. In
the clip, a child is trying to lure a puppy to the child’s
bedroom by laying a trail of crumbs. The child mumbles inaudibly to
himself as he lays the trail. When not watching the video, it is not
obvious that he is laying a trail of crumbs since all you hear is the
mumbling. The audio description that is interspersed with the
child’s mumbling says “Charlie lays a crumb on each stair
leading to his room.” The caption that appears as he mumbles is
[inaudible mumbling].

Example 2: A video clip of a news
story.

A video clip accompanies a news story about the
recent flooding in a major city. The reporter describes what is seen,
for everyone. No audio description is necessary. The captions display
what the reporter is saying.

Example 3: A silent
animation.

An animation shows a pantomime climbing a ladder.
There is no audio track for this animation. No captions or audio
description are required. Instead, a text equivalent is
provided….

Surely we can come up with better real-world examples of a second
language embedded in a paragraph. I also cleaned up WAI’s copy
errors below.

Facilitating unambiguous decoding of characters and words
in content is also helpful for individuals who are learning to read
or learning a second language….

In the following sentence, “And with
a certain je ne sais quoi, she entered both
the room, and his life, forever,” the French phrase je ne sais quoi is marked as French. Depending on
the markup language, English may either be marked as the language for
the entire document except where specified, or marked at the
paragraph level.

Provide a summary for relationships that may not be obvious from
analyzing the structure of a table but that may be apparent in a
visual rendering of the table.

If
contracted forms of words are used such that they are ambiguous,
provide semantic markup to make words unique and interpretable.

Here
is where standardistas shine. We’re obsessed with the
proper use of lists, headings, and other XHTML elements. Time to give
WAI a taste of our glorious compliant medicine. We may have a problem
finding examples of “chapters” and
“sections,” because, although they are defined as
“relationships” of the link
element, there are no HTML elements for chapters or sections.

(This passage of the WCAG is particularly pathetic, resorting to
citing the structure of a bicycle to explain web structure.)

The content has been reviewed, taking into account the
following strategies for facilitating orientation and movement,
applying them as appropriate.

Revealing important non-hierarchical
relationships, such as cross-references, or the correspondence
between header and data cells in a table, so that they are
represented unambiguously in the markup or data model

Dividing very large works into sections
and or chapters with logical labels

Others?

How many “expanding outlines” and “dynamic fisheye
views” have you run through the W3C validator lately?

site navigation
mechanism

A site
navigation mechanism is a mechanism for easily orienting and
moving about within the site. Site navigation mechanisms include but
are not limited to:

A
home page with hyperlinks on it and subsequent pages that link to the
other pages at the site

Site map(s)

Search engine(s)

Expanding outline(s)

Dynamic fisheye views showing all linked pages or topics
related to any page.

The content has been reviewed, taking into account the
additional ideas listed below:

Place navigation bars in a consistent
location whenever possible

Similar layout for user interface
components should be used for sections or whole site

Similar user interface components should
be labeled with similar terminology

Use headers consistently

Use templates for consistent presentation
of sections or whole site

Pages with similar function should have
similar appearance and layout

Controls that look or sound the same
should be designed to act the same

Conventions likely to be familiar to the
user should be followed

Unusual user interface features or
behaviors that are likely to confuse the first-time user should be
described to the user before they are encountered

Popup
windows and frames are among the recurring W3C bugbears that are
hardly ever used. Still, surely we can find better case histories
than these.

Example 1: A form to deactivate
pop-up windows.

A checkbox is provided on a page of links to let
the user select whether they want the resultant pages to appear in
new windows or not.

Example 2: A warning given before a
pop-up window.

At the end of a news story, several links are
provided for more information. At the beginning of each link is an
icon of an arrow with the text equivalent, “Link will open in
new window.”

Example 3: Frames that do not track
history making the back button behave unexpectedly.

Example 4: Forms.

Editorial Note: Some of these
examples are very brief. Should they be expanded and clarified with
further details?

Unclear on the concept

These guidelines show such a deep misunderstanding of the topic they
pretend to tackle that they should be deleted or massively rewritten.
Where you can help: See if you can figure out what they are intended
to mean and rewrite them. Or suggest reasons, preferably backed up
with references to real-world sites and development practices, why
they should be deleted.

Does anyone, at all, anywhere, use blinking text anymore, and if so,
how many of those people are using “client-side
scripting” to do it rather than simply using blink or <a
href="http://www.w3.org/WAI/UA/TS/html401/cp0303/0303-CSS-BLINK.html"
id="text-decoration-blink" title="text-decoration:blink in the style
element">text-decoration:blink? How many user stylesheets
can override scripts?

Client-side scripting is used to create blinking
text. The user can deactivate the use of scripting in his or her
browser or override the use of scripts with a user style sheet.

Unicode
encoding is desirable, but it is not the only encoding available,
nor does its absence impair accessibility.

Text in the content is provided in Unicode or sufficient
information is provided so that it can be automatically mapped back
to Unicode.

This guideline concerns captioning of web multimedia. Its plain
reading requires a transcript of all real-time audio broadcasts. That
is, every single Internet radio station would require transcription.

Meanwhile, if you have any kind of webcam at all, you need to
scrounge up some other site you can link to that is somehow the
“equivalent” of the webcam’s image.

If the web content is real-time and audio-only and not
time-sensitive and not interactive a transcript or other non-audio
equivalent is sufficient. [...]

If the web content is real-time non-interactive video (e.g., a
webcam of ambient conditions), either provide an equivalent… (e.g.,
an ongoing update of weather conditions) or link to an equivalent…
(e.g., a link to a weather website).

The Web Accessibility Initiative misunderstands the use of cascading
stylesheets. Here
it requires you to come up with a different appearance for dozens of
HTML elements. (Should the elements em,
cite, and i really look different?) It also
requires you to code special black-and-white and monaural stylesheets.

The structural elements present have a different visual
appearance or auditory characteristic from each other and from body
text. [...]

The structural emphases are chosen to be distinct on different
major visual display types (e.g. black and white, small display, mono
audio playback). [...]

For auditory presentations, use different voice
characteristics and/sounds for major headings, sections and other
structural elements.

If content is targeted for a specific user group and the
presentation of the structured content is not salient enough to meet
the needs of your audience, use additional graphics, colors, sounds,
and other aspects of presentation to emphasize the structure.

Foreground/background
distinctions are, as they say, a personal thing. WAI has provided
no evidence that authors can reasonably anticipate how a person with
a visual impairment or learning disability will be confused by
figure–ground combinations. Further, who runs in “256
grayscale” anymore, let alone black and white (i.e., one-bit
colour, like the original Macintosh)?

When text content is presented over a background image or
pattern, the text is easily readable when the page is viewed in 256
grayscale.

Text content is not presented over a background image or
pattern or the text is easily readable when the page is
viewed in black and white (no grayscale).

Audio content does not contain background sounds
or the background sounds are at least 20 db lower than the
foreground audio content.

Text content is not presented over a background image or
color or the colors used for the text and background or
background image pass the following test:

No tests/algorithms are available at this
time

WAI has not recognized that many, or even most, web-based games are
going to be inaccessible to someone. It doesn’t make a lot of
sense to warn of an unpredictable response, thus making it
predictable.

Where inconsistent or unpredictable responses are essential to the
function of the content (e.g. mystery games, adventure games, tests,
etc.) the user is warned in advance of encountering them.

The current drafts are a huge improvement over earlier suggestions,
but WAI still clings to the notion that “content” can be
“reviewed” to demonstrate that it is as simply written as
possible. But write too simply and you may alienate your target
audience. Here accessibility turns from making sites accessible to
rewriting your own work — and making you illustrate it.

Content is written to be no more complex than is necessary
and/or supplement[ed] with simpler forms of the content.

the content has been reviewed, taking into account the
following strategies for evaluating the complexity of the content,
applying them as appropriate.

Familiarity of terms and language
structure

Reasonableness of length and complexity of
sentences

Coherence of paragraphs (and sensibility
in length)

Clarity of headings and linked text when
read out of context

Accuracy and uniqueness of page titles

Care in the use of all-capital letters
where normal sentence case might increase comprehension

Inclusion of non-text content to
supplement text for key pages or sections of the site where they felt
it was appropriate.

Backward
compatibility. There’s only so far back we can go in a
world where nearly everyone uses a Version 5–or-later browser
and authors are writing valid HTML and CSS, which are themselves
supposed to be compatible across browsers and devices.

As ever, there’s much discussion of people with outdated
technology, which is an accessibility issue in a sense other than
those within WAI’s purview. Everybody else has to upgrade; why
are people with disabilities exempt? Should standards-compliant
progress on the web be hindered because someone somewhere might be
using an old screen reader?

Nor is there any understanding of the new and more valuable concept
of progressive enhancement — using
baseline HTML and CSS to be compatible with any compliant device, but
adding features that more-sophisticated devices can use.

Individuals can identify (either through site
documentation or automatically through metadata) whether or not they
are likely to be able to use a site. In conjunction with a search
engine or a proxy server, this could be used to automatically filter
out sites a user cannot access or to automatically filter to the top
sites that would be most usable.

Requiring sites to document their baseline will
cause them to evaluate assumptions about user agents and will
minimize the number of sites that are inadvertently inaccessible
because they are unaware of backward compatibility issues.

Benefits of designing for backward
compatibility:

Individuals who must use alternative browsing
technologies and devices will be able to access the content.

Individuals who cannot afford or otherwise do not
have access to newer technologies also benefit from backward
compatibility in that they will not need to purchase upgrades or
equipment as often.

Next to impossible

The Web Accessibility Initiative publishes the following draft
guidelines even though they are actually or nearly impossible to
implement. Here we need you to provide technical explanations, which
WAI members should have been able to come up with themselves but have
not. Or you could nominate examples from the real world and explore
how difficult it would be to apply the guidelines to them.

“Collating” a “script” of audio descriptions
and captions has been done exactly once in recorded memory —
for a demonstration project that is not documented online. It is
impossible in practice due to the lack of interchange formats for
captioning, audio description, and related fields. Nor are there that
many examples of multimedia that are captioned and
described. It’s even rare, when you consider the full range of
TV programs and movies, to find both captioning and description in
those well-established fields.

Live captioning is extraordinarily difficult for online media (nearly
impossible using standards-compliant code), while live description
has been attempted a mere five times in the broadcast sphere.
Meanwhile, of course captions require you to read and watch
at the same time. This isn’t telepathy.

a text document that merges all audio descriptions and
captions into a collated script (that provides dialog, important
sounds and important visual information in a single text document) is
provided.

captions and audio descriptions are provided for all live
broadcasts which provide the same information.

the presentation does not require the user to read
captions and the visual presentation simultaneously in order to
understand the content.

It’s impossible to write a stylesheet that detects
the size and colour capabilities of a display and serves
different commands as a result. Almost nobody uses black-and-white
displays; audio stylesheets are effectively unsupported, and stereo
audio is the norm. The guideline also apparently requires
stylesheet-switchers on each and every site. The concept of
“vary[ing] the emphasis of the structure” is rather hard
to understand, unless it means making certain elements invisible or
yet other elements render in 96-point type.

The structural emphases are chosen to be distinct on
different major visual display types (e.g. black and white, small
display, mono audio playback).

Content is constructed such that users can control the
presentation of the structural elements.

Alternate presentation formats are available to vary the
emphasis of the structure.

This guideline,
intended to help dyslexics and others with related learning
disabilities, presupposes a Windows-style combo box (drop-down list
plus type-in field). It would also require you to spell-check every
input ever made on your website. That would seem to be the
visitor’s responsibility, and it’s already
possible.

Where possible, the user is allowed to select from a list
of options as well as to generate input text directly.

Errors are identified specifically and suggestions for
correction are provided where possible.

Checks for misspelled words are applied and correct
spellings are suggested when text entry is required.

Not our problem

The Web Accessibility Initiative’s Web Content
Accessibility Guidelines are intended “to make web content
accessible to people with disabilities.” Yet these proposed
guidelines for WCAG 2.0 extend well beyond web content into unrelated
technical fields and, indeed, the mind of the author.

Here your contribution can be an expert opinion on how the proposed
guideline would apply to your site. Would you fail, pass, or fall
somewhere in between? Would it even be possible for you to assess
whether or not you comply? How would a Web Content
Accessibility Guideline such as this affect your web development?

Do you want the Web Accessibility Initiative dictating to you how
“complex” or “unfamiliar” your content might
be, or even whether it might be complex at all? If using data tables,
won’t you already be using correct table markup?

Content is considered complex if the
relationships between pieces of information are not easy to figure
out. If the presentation of the information is intended to highlight
trends or relationships between concepts, these should be explicitly
stated in the summary.

Examples of complex information:

Data tables,

Concepts that are esoteric or
difficult to understand,

Content that involves several
layers.

unfamiliar content

Content might be unfamiliar if
you are using terms specific to a particular community.

Abbreviations
and acronyms are a problem that may never be satisfactorily
resolved, at least not until screen readers — the main sticking
point here — are upgraded to handle them better. Meanwhile, the
discussion of diacritic marks is an attempt to force authors to write
Arabic and Hebrew with the vowel markings that are generally deleted
in adult-level writing — again all because screen readers
cannot handle the writing system as grownups use it.

Abbreviations and acronyms are clearly identified each
time they occur.

Symbols such as diacritic marks that are found in standard
usage of the natural language of the content, and that are necessary
for unambiguous identification of words, are present or another
standard mechanism for disambiguation is provided.

How to contribute

If you have anything to contribute to the WCAG 2.0
development process, you can post a message to the WAI-GL mailing
list (wai-gl at lists.w3.org).

You’re also requested to post to
another list, public-comments-wcag20 at w3.org.

I certainly encourage you to publish comments on your own
weblogs, with links sent along to the mailing lists. That will get
the message out to more readers, and also put a bit more public
pressure on the Web Accessibility Initiative to create better
guidelines.