How to Save Web Accessibility from Itself

As is now quite widely known among indie developers and virtually
unknown everywhere else, websites are properly created in accordance
with published accessibility standards. The chief source for those
standards is the set of “recommendations” by the World Wide Web
’s Web Accessibility Initiative (the W3C WAI). These Web Content Accessibility Guidelines (WCAG 1.0)
were last officially updated in 1999.

Article Continues Below

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#section2

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

The participation problem#section3

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,

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

WAI Interest Group. General discussion of web
WAI Guidelines, home of the Web
Content Accessibility Guidelines Working Group
. Discussion of
current and future guidelines.

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

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#section4

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:

  1. Rewrite: The guideline
    needs rewriting and clarification
  2. Examples: The guideline
    requires many more examples, preferably drawn from actual websites
    (anonymized if necessary)
  3. Unclear on the
    : There’s something wrong with the basic
    idea of the guideline
  4. Impossible: The guideline, as written, is
    impossible to meet or virtually so
  5. Not our
    : The issue cannot reasonably be solved
    through guidelines governing web content

Deficiency report#section5

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#section6

WCAG 2.0 is a moving target.

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

Action items#section7


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.

  1. Overview of Design Principles: Here, the four themes or
    “goals” of WCAG 2.0 are somewhat clumsily named as



    • Perceivable
    • Operable
    • Understandable
    • Robust
  2. Make content perceivable by any user. The checkpoint needs fixing. Could you implement it
    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.

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

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

    3. 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).

  3. What is “non-text content”?

    Non-text content includes but is not
    limited to images, text in raster images, image map regions,
    animations (e.g., animated GIFs), ASCII art, images used as list
    bullets, spacers, graphical buttons, sounds (played with or without
    user interaction), stand-alone audio files, audio tracks of video,
    and video….

  4. 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.

  5. 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.

  6. Definitions should be definitive. These


    Content is the information or
    meaning and function.


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


    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.


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

  1. 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.

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

    2. 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).

  2. 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

      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

      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

      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.

  3. 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.

  4. 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

      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

      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

  5. 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.

  6. The WAI is unaware that correct table markup makes table structure
    crystal-clear. Also, exactly what “semantic markup” could
    make, for example, homonyms, homographs, and figures of speech

    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.

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

  7. 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
    , 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.)

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

      1. Breaking up text into logical

      2. Providing hierarchical sections and
        titles, particularly for longer documents

      3. 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

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

      5. Others?

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

    site navigation

    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.

    • 3D
      virtual representations of site content

  9. Better examples of consistent
    site layout
    , anyone?

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

      1. Place navigation bars in a consistent
        location whenever possible

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

      3. Similar user interface components should
        be labeled with similar terminology

      4. Use headers consistently

      5. Use templates for consistent presentation
        of sections or whole site

      6. Pages with similar function should have
        similar appearance and layout

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

      8. Conventions likely to be familiar to the
        user should be followed

      9. 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

  10. 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#section10

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.

  1. Unicode
    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.

  2. 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).

  3. 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). […]

    1. For visual presentations, use font variations, styles,
      size and white space to emphasize structure.

    2. Use color and graphics to emphasize structure.

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

    4. 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.

  4. Foreground/background
    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)?

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

    2. 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).

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

    4. 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

  5. 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

    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.

  6. Here is the single biggest minefield in which the Web Accessibility
    Initiative finds itself: Writing guidelines for learning-disabled people,
    who, the WAI is unable to acknowledge, may never be significantly accommodated online.

    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.

      1. Familiarity of terms and language

      2. Reasonableness of length and complexity of

      3. Coherence of paragraphs (and sensibility
        in length)

      4. Clarity of headings and linked text when
        read out of context

      5. Accuracy and uniqueness of page titles

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

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

  7. Backward
    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.

    Benefits of determining and documenting baseline user agent

    • 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

    • 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#section11

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.

  1. “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.

    1. 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

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

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

  2. 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.

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

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

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

  3. 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

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

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

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

Not our problem#section12

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?

  1. 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

    unfamiliar content

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

  2. 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.

    1. Abbreviations and acronyms are clearly identified each
      time they occur.

    2. 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#section13

  • 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
  • You’re also requested to post to
    another list, public-comments-wcag20 at
  • Both lists have archives on the web (WAI-GL, Public-Comments).
  • There’s also a Bugzilla implementation for
    , though you’re not allowed to
    “discuss” issues there
  • WCAG holds a few “f2f” meetings each year; the next is in Tokyo.
  • 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

26 Reader Comments

  1. I agree, but surely (and like the British Standards Institute in the UK) the W3C are at least making vested efforts to bring about standards.

    The interpretation of ‘standards’ is an issue which can’t be resolved unless specific lines of code are defined (which is basically impossible!).

    So hats off to W3C, and lets see if some ‘standards’ can be forged using best practices by the wider web community…

  2. Joe’s arguments make a lot of sense; it certainly would seem that the WAI is making similar mistakes with WCAG 2 as those made when drawing up WCAG 1.

    I provide training on Web accessibility and focus on practical subjects like navigation, images, forms and tables, rather than attempting to follow the 65 (!) WCAG 1 checkpoints. WCAG 2 unfortunately fails to simplify the requirements by reducing the numbers of checkpoints and compliance levels but increasing their scope and, perhaps, their ambiguity.

    Perhaps part of the problem is that public authorities and organisations are adopting WCAG 1 (and soon, presumably, WCAG 2) as ‘standards’, forgetting that they are guidelines. A site may not reach Level AA (to be replaced with Core+) compliance, but its designer might be well-versed enough in Web accessibility techniques that the site is more accessible than another that purports to achieve Level AAA.

    Yes, more examples drawn from the day-to-day practicalities of designing and using Web sites are needed to illustrate the principles of Web accessibility — but also to inform the WAI about what users with disabilities are using the Web for and how they do it, so that we can make Web sites that they can and like to use.

  3. This is the most important article ALA has run in a long time and I hope it will get the desired response. You’ve done an ace job of breaking down a long, incomprehensible document into red flags and action items. There’s a huge disconnect between the scientists at the W3C and those of us who create Web sites. Many of us get our standards and accessibility information not from the W3C but from its interpreters who speak English and common sense (you, Eric Meyer, Zeldman, WSP, Pilgrim, Scott Andrew, etc.).

    There’s another disconnect between the Usual Suspects who incorporate standards and accessibility into design (Bowman, Shea, Hicks, Pick, Cederholm, Zeldman, etc.) and other strong designers who focus on pushing the envelope. I’d love to see the W3C sit down with Matt Owens, Trevor Van Meter, Cuban Council, etc., look at some of the award winning work being done, and figure out how leading edge graphic design and accessibility can merge. Maybe a summit meeting?

    Anyway, the longest journey begins with the smallest step, and this article is a big step in the right direction. Thanks.

  4. <<<>>

    1. I seriously doubt that will ever happen.

    2. No need to scare developers with some vague “in-the-future” threat.

    This reminds me of the situation a couple of years ago when all the pressure was on designers to completely abandon tables for layout (the proponents have since “recanted”). Accessibility is all fine and dandy, but people should make their own decision as to what is best for the sites they are creating.

    The dream of a site accessible TO ALL is just that: a dream.

  5. >>>I seriously doubt that will ever happen.

    Already many sites are legally mandated to observe WAI-derived guidelines such as Section 508 of the Workforce Investment Act in the U.S.

    When the next generation of guidelines is written, it’s not improbable that laws governing the accessibility of Web sites will be updated accordingly.

    On that level alone it is in the interest of people who create sites to help ensure that the guidelines actually make sense and are achievable.

    That said, even if all accessibility-related laws stayed as they are (or even if they went away, which won’t happen) it would still make sense for designers to involve themselves in the process of creating clear, usable, achievable accessibility guidelines.

    Why? Because many of us want to make more accessible sites, and good, usable guidelines can help us do that. Unclear, confusing, or unrealistic guidelines will not help.

    You may not ever be legally mandated to make your site(s) accessible. You may never have clients who care about it. You may never, not even in the next 20 years, personally have an interest in it or a change of feeling about it. But you might!

  6. Great article. I intend to re-read it and then head over to see what I can contribute. Accessibility is becoming a requirement with more and more clients, and I would like to be involved with this process.

  7. Joe Clark is a seriously intelligent and well-informed commentator. From what I can see, this is better and wider-ranging than his FIR article. Like Ben, I’d have to read it more than once.

    I’m not sure about the re-wording task. It’s a nice parlour game, and I’d like to try it. But my understanding of translation is that this approach is less than ideal. They tried this with the New English Bible and the end result does not rival Tyndale.

    Tyndale translated well because he was properly at home in both languages. What is needed is someone who understands the Web languages involved – and all the issues around their use – and who can write simple clear direct, properly colloquial, English.

    But, as Joe says, contributing to the discussions would be good.

  8. If Browser vendors were required to release a ‘accessibility view’ function with all of their browsers you could switch easily to a text only, properly alligned, etc, interface. This would cause developers and designers the world over to take notice.

    I propose that browsers be made to integrate a standard ‘accessibility view’, perhaps even designed as an open module of code by the W3C, the WAI or the development community at large.

    This would create a snowball effect of develpers and designers knowing that their sites were, exactly, designed to be accessible. Without browser support, we will have no common design. And without a common accessibility design goal, we can have no common accessibility.

  9. Interesting article 🙂

    The WAI has stepped away from a rigid definition of what web content might be and has instead started trying to describe ‘all’ content in the broadest and most abstract terms. My feeling is they are now lost in the territory of linguists and utterance interpretation, the murky academic provinces where sense is sought of the “how” and the “why” of what we say, mean or do — seriously confusing stuff (one of these maniacs should be able to help though:

    Perhaps an interim solution would be to narrow the scope of what content bits need to be made accessible?

    If we assume the key issue is equal access to information — or at least lack of overly privileged access to information the by non-disabled — then the question becomes

    “Does the non-disabled person have privileged access to this information beyond that inherent to his lack of disability?”

    The graphic “/cognima_diag.gif” on page conveys information about what a piece of software does.

    The alt tag says “diagram: The Cognima Server at the network operator mediates between content on the one hand and subscribers on the other”

    The sighted user gets the info about how the product is used, but the graphic also conveys unspoken branding messages about the company “This company wants to make complex things clear and simple to understand” “This company’s products are simple to use, fresh, cool, upbeat” and so on.

    My point is that the WAI should not ask us to convey these ‘indirect’ messages in writing — that’s just silly. Instead, by keeping the alt tag to the factual information the site’s designer does not disadvantage the disabled user but also, does not restrict the sighted user’s experience.

    Similar common sense stuff could be used for structure.

    Test your site in Lynx. Can you use it? Does it make sense, provide all the functionality and information it does in Internet Explorer?

    If not, then the same question applies:

    “Does the non-disabled person have privileged access to this information beyond that inherent to his lack of disability?”

    If your site is a game, then of course not — a sighted person is always going to be better at aiming a gun.

    If your site is an online bank, then you are giving the non-disabled an unfair leg up.

    In a nutshell, it comes down to effort and discipline. It can be a pain getting sites to work properly without hacks but if you don’t, you’re being lazy 🙂

  10. I personally have never liked W3C’s explanations of anything.

    Back in the day when I started learning HTML I took a copy of the homepage (when it was still active) which was a BIG three column page and essentially table hell, but I learned more about the code there then anywhere on W3C. They haven’t improved much since then which was 1998. Their specs are difficult to understand. Their site has nearly no navigation besides the link to the homepage. Directory navigation sort of comprehendible but not memorable (Just like the w3c not to use plain english in there directory structure also! Ex. Using when something like will be more memorable to visitors and make use of a directory structure that follows the page title ‘Web Content Accessibility Guidelines 2.0’)

    Semantic code, separation of content and design are both good ideas that have origins in the W3C’s Recommendations. The W3C have done a lot to improve the web’s accessibility especially with XML, its variants, and stylesheets. They just don’t teach it very well.

    I do agree with this article though. A severe rewording/reworking of the Accessiblity Guidelines is a must. I have one major complaint so far about the guidelines. Why do they have to rule out images so often when making an accessible site? There are more than just blind/visually disabled people on the net. I think they might learn a thing or two from ( WebAIM and this interesting article on ( accessibility.

    OK, now I’m done venting, thanks ALA for sparking up this conversation though.

  11. “Abbreviations and acronyms are clearly identified each time they occur.”

    Wasn’t that the FIRST time they occur before? Doesn’t anyone else find including acronyms for everything often makes a mess of the text?

    I’ve started using a Glossary of common acronyms instead down the side of my site. Not sure if it’s a good idea or not.

  12. “If Browser vendors were required to release a ‘accessibility view’ function with all of their browsers you could switch easily to a text only, properly alligned, etc, interface.”

    Your solution is unworkable. Accessible websites are not necessarily text only. This is a common straw man argument. An accessible website is one that doesn’t prevent or obstruct a visitor from accessing the content. Text-only websites can also be inaccessible.

    Accessibility is a two stage process: 1.) Remove barriers to accessibility. 2.) Add in accessibility features.

    A browser could possibly handle 1.), but it can never satisfactorily accomplish 2.) since it is missing the information you need to have given it. Making websites accessible isn’t a browsers job alone. It isn’t a web designers job alone. It is the job of both groups together to deliver an accessible website.

    Offloading an impossible job to the browser is just not on.

  13. I have to start off by saying that I only had time to skim Joe Clark’s article before writing the following comments. So, don’t attribute anything of what I am about to say to him. Thanks.

    I have concerns about how accessible WAI material is to people (such as myself) who are interested in accessibility issues but are not technical.

    To combat this problem, I have set up a monthly group to study the Web Content Accessibility Guidelines (version 1.0). The first meeting is tonight (11/17). I am amazed that I had to start a group like this, that no other ones exist.

    As for participating in a working group with the WAI, I’ve been told that I need to participate in a two-hour conference call every week, which is impossible for me because I can’t take that much time away from my work day AND because I am hearing-impaired. It’s ironic that a group that promotes accessibility would set up an accessibility barrier for a potential volunteer with writing experience, when writing experience is sorely needed by the WAI to make it’s material more accessible to those who are not technical.

  14. Meaning of title: Any game that is too hard will have few if any players, and thus no one watching (or benefiting). It will be only unactualize theory.

    After seven (7!) months of trying to upgrade my service-oriented site to full CSS (done), and WAI Level II standards (done), while getting it to work in the zoo of browsers in use (done), I’m so tired and peeved that I can’t find the words to describe it. I’ve been programming for 30 years, but I’m a counselor in real life. I do my site to help my peers. I’m not a web design/production professional, and I don’t have a budget. My revised web site still hasn’t seen the light of day, and I personally haven’t seen much of that light, either, for months. This is nuts.
    I find it inexplicable and inexcusable that existing supported browsers still can’t meet standards acceptably. So we get to hack away. But I can’t. Can’t afford the time costs.
    I find also it inexplicable and inexcusable that the W3C and the WAI, along with supposed leaders like Microsoft, cannot seem to understand the needs of the common woman and man. Computers in general, operating systems, the bloody WAI accessibility guidelines aren’t accessible. They’re not even understandable. So…the majority of the population, being left out, turn their back. I’d give a lot for fewer tricks and MUCH more reliability and ease of use. It’s about priorities, and I now set my own.
    Where this all takes me is in the direction of SIMPLE. I now do as little as possible. I’m not waiting for any new light. If it comes, good, but meanwhile, I have work to get out. When you have water to carry, you may not have time to wait for stainless steel buckets. I don’t.

  15. Hard to care greatly about accessiblity when ALA and how many others insist on styling text in a marginally legible color. Like, what? You’re so right! My problems with reading your text don’t exist! How could I not know that my use of your site doesn’t count. If *only* I were visually impared.

  16. Bob:

    Text color is #444, a web-smart medium-dark grey. Background is #fff, pure white.

    While #444 over #fff is not as strong in contrast as #000/#fff (the ultimate contrast), #444 is pretty darned dark and the contrast is fairly strong and quite legible unless your monitor is wildly out of step with the wide range of normal gamma settings.

    When I speak of normal gamma settings I’m not talking about bothering to calibrate your monitor and set it to the accepted sRGB standard. I’m talking about a wide range of fairly random factory settings, since most users (including some web professionals) don’t calibrate and don’t set their monitors to the standard sRGB baseline.

    Even on a Macintosh laptop set to the traditional Mac screen gamma (which is considerably brighter than most PC settings), I can’t reproduce the problem of marginal legibility you describe. I see good contrast between foreground and background.

    I hope you’re not saying that any site that doesn’t use 100% black text on a 100% white background is illegible to you.

    If you are saying that, you may want to visit your control panels and adjust your gamma to bring it closer to the norm. Not only will doing so make it easier to read text on the web, if you’re a designer, developer or content person it will also help you get a more accurate idea of what your site looks like to the “average” reader. (Admittedly, gamma variants are so all over the place that there is norm.)

  17. apartness — You say, “I can’t reproduce the problem of marginal legibility you describe. I see good contrast between foreground and background.” That’s a judgment call. The whole point of accessiblity is that one person’s judgement *doesn’t* substitute for another’s experience.

    As it turns out, *I* find #555 over #fff hard to read.

    What’s hard mean? Squinting. Concentrating. Feeling the eye muscles contract and re-contract, to compensate for a text that’s at the (upper) limits of legibility … Leaving the site early, before I’m done.

    Having said all that, I wonder if ALA’s legibiltity issues are compounded by a text color that’s similar to the background color framing the content: DARK background – light background and DARK text – DARK. Maybe creates a visual conundrum that some eyes struggle to understand.

  18. See if it’s any better now. I’ve darkened it a bit more. You make an excellent point that one person’s judgement doesn’t substitute for another’s experience. I absolutely agree. At the same time, to some extent, judgement and experience are all any designer has to work with.

    We know that if we put black text on a white background and use blue links, almost nobody will have a hard time with that color scheme, regardless of vision, gamma settings, monitor age and quality, etc. Yet we can’t limit the entire web to black text on a white background with blue links.

    We know that some color combinations represent a particular problem for people with particular types of color-blindness, and we try to avoid those color combinations. We also try to avoid combinations that will shift severely in 16-bit mode. But there are many variables. What is orange on a Mac might be brown or vaguely purple on a Dell monitor left at its factory settings.

    (Similarly: what to you is a dark background at ALA is medium-bright on laptop and Cinema screen tests here. The laptop is set to Apple Standard gamma; the Cinema screen is set to sRGB in the Windows gamma space. In both cases the background looks almost washed out; yet to you, it is dark. I don’t dispute your experience, I’m merely saying there’s a lot of variation out there and it’s impossible to predict how a color will look from one viewing situation to another.)

    Sometimes your judgement tells you something works — and testing seems to verify it. Yet a reader’s experience will tell you otherwise. So you go back in and tweak. Which is what we’re constantly doing.

    Thanks very much for your valuable feedback.

  19. OK, the way I see it, Jakob Nielsen is over-confident in his reliance on feedforward analysis. It’s not surprising that his encyclia miss as much as they net. Like, when was the last time JN & Group saw that separating content from design makes the real-world usability problems of a site rectifiable in real-time, based on real-world user experience. Based on feedback. Dialogue between site users and site designers — A dimension of usability and accessibility as key to site success as the guideline on where to place the search box … Which is to say, thanks for increased contrast between text and background. Makes a difference to my eyes.

  20. “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)?”

    I found this rather amusing. I do not believe that the recommendation of 256 greyscale and black and white legibility is because of people actually running in that mode. I guess you haven’t heard of the design technique in converting to greyscale to check contrast.
    It’s a pretty reasonable way to anticipate confusion if you ask me.


    (BTW, I see “unclear” is actually an ID on an H3 tag. Have named anchors been deprecated? I acknowledge this is probably more maintainable than having the separate anchor; on the other hand it is a choice that makes same-page links inaccessible to some browsers.)

    It is no longer possible on many video cards to test in 256 grayscale; they don’t make grayscale available as an option. It’s a pity, as some people do see the world in grayscale.

    “live description has been attempted a mere five times in the broadcast sphere”

    Not to minimize the difficulty or expense of this, but I would put the number of attempts in the thousands. It’s called sportscasting.

  22. In reference to my parenthetical comment on breaking same-page links in my preceding post, I see the relevant W3C recommendation here:

    (which is on a page which is XHTML 1.0 strict and which works)

    This looks like future XHTML plans will conflict with the backward compatibility requirement.

    And I withdraw my “some browsers” comment and replace it with “Netscape 4”, as I see IE 5.1/Mac, iCab 2.9 and Lynx accept the same-page link to an ID.

  23. That is the anchor C_8

    (which is on a page which is XHTML 1.0 strict and which works in Netscape 4)

    so I can’t use same-page links in Netscape 4 on ALA. this is a shame, as I find the text much easier to read in Netscape 4 where it is black on white and not gray on white, which I, like Bob, find tiring to read.

    I have a problem with the idea of having to adjust my monitor, which is set to Mac standard gamma but which is aging, for a particular site. But if you put an id of “alistapart” on your body tag, I could override the text colors for your site in my personal style sheet (in the aware browsers) in the compliant browsers, according to some article or other I read.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA