Further on a topic that my nontechnical readers assuredly don’t care about, WCAG 2: Even academic researchers with Ph.D.s cannot follow the damned thing!

“Communication Challenges in the WC3’s Web Content Accessibility Guidelines” by Catherine M. Brys and Wim Vanderbauwhede (abstract; large PDF) reviews a November 2004 “draft” of WCAG 2 from the perspective of communication theory. (Trivia: The title of the paper errantly writes “WC3.” Brys is a Ph.D. engineeress. Were she working in Ontario, she could write “Ph.D., P.Eng.” after her name, a sequence sometimes pronounced “fud peng.”)

En tout cas, the paper finds very little cause to laud WCAG 2. (Some related items grouped together in these excerpts.)

  1. [T]he authors of the Requirements document express the need for clear and simple language…. Unfortunately, the Requirements document seems to have been ignored by the authors of the Accessibility Guidelines….

    Language and terminology incorporated throughout the Accessibility Guidelines are, in our opinion, not sufficiently aimed at non-technical audience segments such as managers and policymakers. Examples include terms such as “general flash threshold,” “red flash threshold,” “content negotiation,” and “URI pattern”…. Many of these technical phrases stem from an attempt to be extremely accurate. However, these technical details make it impossible for all but the most technical readers to understand and, consequently, comply with the Accessibility Guidelines. The red flash threshold is a case in point: it is in practice not possible to measure the total noncontiguous flashing area of a Web page. […]

    The Accessibility Guidelines immediately start with very detailed information – high-level information is completely lacking. This approach does not cater well to managers and policy makers who typically want high-level information. [Examples cite several uses of the phrase “programmatically determined.”] […]

    [T]he main part of the Accessibility Guidelines, consisting of the principles and guidelines, uses technical terminology and includes very detailed information. This technical nature contradicts the claim that the Accessibility Guidelines are indeed aimed at a wide and nontechnical audience…. WCAG 1.0… suffer[s] from the same issues, as confirmed by a study….

  2. Device-neutrality is fine as a goal, the authors tell us, but in practice Web developers are going to be using some technology to implement the guidelines.

    [A]ll audience segments use the WCAG with a very concrete goal in mind. The abstract principles and guidelines are unlikely to cater to any of the audience segments.

    The Accessibility Guidelines seem hard to read for any of the document’s intended audiences, but especially for non-technical audiences. Awkward and wordy phrases are often used. […] [I]n our opinion, it is not possible for the document to achieve its purpose for its intended audience without considering the technology available to the audience. […]

  3. Plain English is not necessarily the answer. The article cites other sources attesting that plain English doesn’t necessariliy work for English-as-a-second-language readers. In WCAG 2, “[s]ome terms are hard to understand”:

    • Content must be perceivable.
    • Interface elements in the content must be operable.

    The Oxford Advanced Learner’s Dictionary… has no separate entry for perceivable…. Even after consulting the dictionary, a non-native English-speaking content author and Web designer will probably not know what to do to adhere to Principles 1 and 2 of the Accessibility Guidelines.

    Another example given is the adjective alternate.

  4. And if the guidelines aren’t clear, managers won’t know what to ask for in recruiting for jobs:

    [T]he understanding of what it takes to make a high-quality accessible Web site is poor. Emphasis is too often on high-tech, flashy Web sites…. Testimony to this problem is the large number of job ads recruiting Web designers that focus only on programming skills or a mixture of graphic design and programming skills. Few Web-related job ads even mention communication skills. The WCAG clearly have a role to play in conveying to managers the skills involved in accessible Web design.

  5. The authors point out that accessibility and usability are linked and critique the pure-usability guidelines that are included in, and left out of, WCAG 2. (The Working Group has taken a conscious decision to leave out any advice that is purely usability-related, something the authors might not have known about at the time. This decision is asinine on its face and is not very well heeded in WCAG 2, based on the authors’ separate findings.)

  6. There is some criticism of the lack of user testing of WCAG 2:

    When writing a document, it is very tempting to produce a draft, circulate it to a limited number of subject matter experts for review, include corrections, and publish the document in its final form. In our experience, this process is still used widely, notwithstanding the obvious advantages of testing with users… The only mention of completed usability testing on the WAI site is the study carried out by the American Institutes for Research (AIR) in October 2003….

    [U]sability tests should be repeated on the WCAG 2.0. These tests would be very useful for several reasons.

    1. First, review will not necessarily highlight potential causes for misunderstanding. Some guidelines may seem perfectly clear to the reviewers, but they may in fact have interpreted certain information differently than intended by the authors.
    2. Second, testing with stakeholders will bring to light any misconceptions about the stakeholders’ goals and needs. An example is the section on who benefits from Guideline 2.5. This Guideline suggests that people with dyslexia benefit from having the option to spellcheck text they have entered in forms. However, a study… has shown that spellcheckers are only moderately efficient in helping users with dyslexia.
  7. The authors appear to concur with the emerging consensus that “review” of WCAG 2 is as much of a closed process as its creation:

    The only involvement from potential users of the WCAG is through review: Following review by the members of the WCAG Working Group, an invitation for comments is posted on the public mailing list. Unfortunately, only members of a very technical community who subscribe to this or to other specialized mailing lists will actually comment on the WCAG drafts.

    Even if people outside the technical community were aware of the review process, they would be unlikely to comment on the WCAG, given its daunting technical nature. As a result, laypersons are effectively excluded from contributing to the WCAG, a situation that may create the impression that Web accessibility is only a concern for technical experts.

All right. What are their proposed solutions? Among several pages of suggestions are two that may not actually solve the problem – to set up a site about Web accessibility for a nontechnical audience and another one for “the basic/intermediate and the expert audience segments.”

Both of those seem to accept the Matt May–style assumption that a standards document has to be overlong and hard to read, requiring the constellation of satellite documents and how-to manuals that the French seem to want (us) to write. I think it’s quite imaginable that accessibility guidelines could be written concisely and understandably and wouldn’t need a set of cheat sheets treble or quadruple the length of the original.

The foregoing posting appeared on Joe Clark’s personal Weblog on 2006.06.10 12:48. This presentation was designed for printing and omits components that make sense only onscreen. (If you are seeing this on a screen, then the page stylesheet was not loaded or not loaded properly.) The permanent link is:

Values you enter are stored and may be published.


Search for very early blog entries, and for anything else on fawny.org:



Other reading

Topics of interest

Typography ⁓ graphic designTTCCanadian EnglishInversionNeuroanatomy

Archives by date

Just add /year/month/day/ to the end of site’s URL, blog.fawny.org. You can add just /year/month/, or just /year/, if you wish. Years are four-digit, month and day two-digit (with padding zero below 10). For example:

Very old archives are still available.

Archives by category

Copyright © 2004–2019

You enjoy fawny.blog