Two accessibility reports, only one of them recent:

Kelly et al., “Forcing Standardization or Accommodating Diversity? A Framework for Applying the WCAG in the Real World

It’s about twice as long as it needs to be, but the essential argument is that WCAG 1.0 has been superseded by events, meeting it doesn’t guarantee accessibility, and sometimes the guidelines are mutually contradictory.

An initial reaction… would be to call for increased awareness raising and education and training, and possibly for punitive measures to be taken against high-profile non-conformant sites in order to make an example…. Increasingly we have found that user communities have a genuine willingness and desire to provide accessible Web resources, but are beginning to raise questions concerning the challenges in implementing – and indeed the relevance of – all aspects of WCAG. […]

  • Theoretical nature of the guidelines: There is a feeling that the guidelines are too theoretical and are based on a W3C perspective rather than real-world experiences. For example WCAG supporting documentation makes no mention of widely used Web formats such as PDF [inaccessible when WCAG 1 came out] and Flash [barely in use then], yet concentrates on open, W3C technologies such as such as RDF, PNG and SVG which are far from ubiquitous and for which very little practical experiences are available.
  • Dependencies on other WAI guidelines: …[T]his model is inappropriate for Web authors, since developments to Web browsers and HTML authoring tools are outside of their control. The target audience of a particular resource may be quite unable or unwilling to use a user agent that supports the User Agent Accessibility Guidelines….
  • Closed nature of the guidelines: The guidelines require use of W3C formats. Thus they implicitly fail to recognise the increasing emphasis placed on accessibility by vendors of proprietary file formats such as Shockwave Flash and PDF. …
  • Logical flaws of the guidelines: The wording of the WCAG guidelines could be seen to lead to a number of logical absurdities. For example a strict interpretation of the Priority 2 guideline that states “use the latest versions [of W3C technologies] when supported” would mean that a WCAG AA–conformant HTML 4 Web site would be degraded to WCAG A conformance overnight when XHTML 1.0 was officially released!
Wood et al., “Accessibility of museum, library, and archive Web sites,” helpfully available only as a Microsoft Word file or as an untagged PDF output from Quark Xpress

A repetitive and overlong evaluation of U.K. “museum, library, and archive Web sites,” plus a minor comparison to “international” (though English-language) equivalents.

The nut graf? “[T]he most serious problems… clearly require design skills and user testing” (emphasis added).

I counted seven different rewordings, all of them just different enough to make me wonder if they were telling me something new each time, of the basic fact that they used automated testing of 325 homepages and automated and user testing of 25 sites.

Basic findings:

  1. [T]he typical homepage needs to look at approximately six different checkpoints and solve 13 user problems to address 68% of the problems encountered by users.”
  2. 42% of homepages allegedly met WCAG Level A, and 3% met Level AA; since the latter requires valid code, I strongly question even that figure, since the evaluator should manually run the site through the validator to make sure.
  3. Disabled testers could complete the whopping two tasks they were given – such a small number I don’t know why they even bothered – 75.6% of the time. (I refer strictly to number of tasks.)
  4. Yet, on average, all the sites were rated 3.8 out of 7 in an ease-of-use scale. You would expect a rating of nearly 6 out of 7 if respondents could complete tasks three-quarters of the time. This finding indicates that accessibility is multivariate and can’t be boiled down to even two numbers, let alone just one.


  1. Testers were five each of blind, “partially-sighted,” and dyslexic people. They all used the researchers’ adaptive technology, which is not a good idea considering the customizations involved. It is not clear which, if any, subjects did not require adaptive technology.
  2. Testers were asked various questions, one of them a leading question – “whether the Panel members experienced a feeling of being ‘lost’ when navigating around a site.” This did, however, elicit the useful factoid that a museum, library, or archive site that is merely part of a larger organization’s site can have confusing navigation: Which navbar refers to the parent organization?
  3. The researchers came up with a confusingly-named and ill-explained system to add up the number of accessibility errors. Each category of error was given one point, but so was each instance of those errors. There are pros and cons to this approach. For a spacer GIF with no alt text, it’s true that hearing the the word “image” (or whatever) announced n times on a page is annoying, but it really does not constitute n errors. You tune it out after a while, and it’s almost instantly correctable by the author. Now, if x different images lacked an alt text, that’s much worse, because you really can’t tell what each image does, barring some very tedious exploration of filenames and the like.
  4. “The members of the Panel were asked to rate the ease of navigation around the site when attempting the tasks. The mean for all groups was 4.6. The dyslexic users felt the navigation was easier than the other groups…. This is particularly interesting, as dyslexic people often experience particular problems in orienting and navigating in information.” I think this has a lot to do with page complexity and how much information is presented below the fold. A simple page that fits in one screen is usually pretty easy to navigate.
  5. Some of the terminology was vague and inaccurate, as is typical of British accessibility reports:
    1. “The User Panel liked features such as… proper links labelled individually, which means ‘no trawling is necessary.’ ” How does one “label” links any other way than “individually”? (Were they trying to discuss multiple links with the same link text and different destinations?) And what is “trawling”?
    2. alt tags”?
    3. “Text and images do not increase in scale when browser option selected”: Isn’t this yet another reiteration of the chauvinism that I’m Using IE for Windows and If That Can’t Do It Nothing Can?
      1. Only Opera can automatically resize images. (You can use relative sizing, but nobody does, and image dimensions are purely presentational.)
      2. Only IE has a problem resizing text, and only if it’s specified in px.
        1. Similarly: “Partially-sighted participants who tried to increase the size of the display by using such controls, however, noted that this often failed, once again due the hard coding of text size.” Does that mean font size="3"?
        2. And how is the following even sometimes factually true? “[O]nly one problem can be identified solely by automated testing (‘Text and images do not increase in scale when browser option selected’).”

      In a case like this, you the disabled site visitor have to stop using a crap browser.

  6. “Many sites did not support colour change due to the hard coding of this information.” What does this mean? Does the site use something like font color="red"?
  7. “Even when it was possible to change colour schemes, very few users seemed to be aware of this possibility”: Indeed, because it requires a trip through your browser preferences, with uncertain implications for the display of the many sites you will read in a week, or a user stylesheet, which nobody with skills less elite than Tantek’s can put together. (The report tacitly recommends user CSS, but the wording is muddled: “Stylesheets should also allow users to change the presentation of the site by using the accessibility options of their browser.”)
  8. Is this any way to indicate a URL in a written document? “[S]ee, then click ‘museum and gallery professionals.’ ” Admittely, the problem is caused by ungainly redirected URLs at the RNIB’s site.
  9. [T]he most common and serious problems relate to navigation and orientation, not technical accessibility problems that can be addressed simply by modifying aspects of the HTML code of pages”: You need heading elements in the HTML code to make navigation and orientation viable.

The foregoing posting appeared on Joe Clark’s personal Weblog on 2005.05.13 13:35. 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)



This personal Weblog is unlikely to be updated again until my next book comes out. (See Best postings)

Other reading

Topics of interest

Typography ⁓ graphic designTTCCanadian EnglishInversion

Archives by category

Archives by date

Just add /year/month/day/ to the end of site’s URL, 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:

Copyright © 2004–2021

You enjoy

Transgenderism is to be opposed categorically