I paid my £35.83 (including P&P) and, a mere week after I received my invoice, today I got what I actually paid for: PAS 78, “Guide to good practice in commissioning accessible websites” (sic).
There was a rumour afoot that the specification document – unavailable as a downloadable PDF when I placed my order (one of many cockups in the ordering process) – was nothing more than a collection of loose-leaf sheets. I then mused that, to add insult to injury, they might be typeset in Arial.
And lo has it come to pass.
Arial at 14 point, no less. Say, kids, can you try learning something about typography?
- Start by selecting typefaces that don’t make you look cheap, uneducated, and tied to Windows.
- Use fonts that are not knockoffs. (The document is, after all, replete with copyright warnings. STANDARDISTA, VALIDATE THYSELF.)
- Use typefaces that are not replete with confusable character forms, as grotesks are.
- Then learn about useful features like em spaces to separate section numbers from surrounding text, which can avoid unpleasant run-ons like “D.3 W3C WAI resources.” In fact, whitespace of all kinds needs serious addressing.
The specification has a lot of typos and is inconsistent in several places, to be discussed below. However, I believe the authors have succeeded about 85% in achieving a document that teaches untrained people how to manage developers and user testing to arrive at an accessible Web site. A bit more writing might resolve the remaining 15%. (Generally, more sentences do a better job of making new concepts clearer than fewer sentences do. It’s a mistake to try to write tight in cases like these.)
If the document were, additionally, not so unpleasant to read, more people might (a) understand it, (b) refrain from feeling cheated at paying 30 quid, and (c) avoid literal headaches.
And on the subject of cost: I don’t find £30 expensive. However, the actual “content” of the specification (in the year-2000 Web sense of the word) occupies 46 pages, giving us a cost per usable page of 65p.
Review and comments
There’s a small bollocksing of advice on accessibility policy. §6.2.4(g), p. 18: “Contact details (eg email, postal, telephone, textphone and typetalk) for requesting further information about the accessibility policy.” First, why would one bother using anything other than written media to discuss a written medium? (The number of sites wholly or significantly presented in sign language is so small you can count them on two hands.)
Second, Typetalk (note the capital) is the U.K. national relay service. Every deaf person who needs to use it knows about Typetalk. It is not a site operator’s job to provide such instructions, which will not change from site to site. (You always just call Typetalk, then call the voice number.) If you’re the site operator and you have a textphone (TTY), visitors with accessibility questions do not need the relay service – save for the exceptional case of having to call an individual directly, which is what the relay service is for in the first place.
ATAG & UAAG
§184.108.40.206, p. 21, is quite nonsensical in that it seems to require “Website commissioners” to “ensure that Web developers are aware of UAAG. Web developers should promote the use of UAAG by designing Web content that upholds W3C guidelines and specifications so that browsers that uphold the UAAG guidelines will provide an accessible experience.” (Emphasis added. Watch those echoes.)
I suppose they’re trying to say that UAAG-compliant devices, which do not exist, will work best with WCAG-compliant pages, which barely exist. All of that seems axiomatic, if not tautological, but it’s also beside the point, because the “Website commissioner” has no say whatsoever over the design of a user agent. Neither does the developer. You can produce pages that comply with or openly mock, defy, and reject WCAG and doing so won’t affect the UAAG compliance of whatever device you’re using.
In any event, UAAG is designed to handle noncompliant pages, since that is what we have in the real world. (UAAG introduction: “Some requirements of this document take into account limitations of formats, authors, and designers…. A format may lack features required for accessibility. An author may not make use of the accessibility features of a format or may misuse a format…. A useragent designer may not implement a format specification correctly or completely.”)
To make matters worse, “NOTE 1” and “NOTE 2” then go on to contradict this section by saying “It is not the responsibility of the Website commissioner to ensure that the browser used upholds… UAAG” and “It is the responsibility of useragent developers to comply with UAAG.”
The next section (220.127.116.11) states that “ser-agent (or functionality) detection scripts and workarounds will be necessary so that a similar experience is provided for users of popular browsers that do not uphold W3C guidelines and specifications.” No browser achieves that latter goal – at least not perfectly, which is the implication. This section appears to require HTML and CSS hacks – for example (“eg”), to get IE6 to work.
§18.104.22.168 (p. 23) seems to require “Website commissioners” to in turn require developers to document “how to operate” any plug-ins for “richmedia formats.” It isn’t our job to write software manuals. UAAG itself requires accessible documentation at Priority 1.
Annex G (p. 45), “How to select a CMS system” , misses a chance to plug ATAG when listing the following question for suppliers: “Are the CMS control screens (usually HTML pages themselves) accessible?”
The specification (p. 22) suggests that “the full semantics of the language used.” (Subjunctive, please.)
The W3C-recommended (current) specifications include:
Hypertext Mark-up Language (HTML) 4.01…
NOTE This is generally used as a development format.
It’s generally used as a what? (Cf. Bruce Lawson.) Is this like training wheels? You start out with HTML and graduate to something bigger, like XHTML 1.1? HTML is a perfectly viable and accessible language for almost all Web documents that do not require Japanese furigana or other
rubyannotation (limited indeed to XHTML 1.1, unless you want to write your own DTD).
A lot of smart people are using HTML to avoid the entire issue of serving XHTML documents as XML.
By the way, XHTML 1.0 is listed as a format that “can be used… for mobilephone browsers.”
§7.3.2 (p. 22) states that “he W3C-recommended (current) specification for CSS is Level 2,” which is correct but somewhat superseded by the fact that 2.1 is finally almost done and is widely implemented already. Also, the specification never defines “XSL” (§7.3.3).
- p. iv: “This Publicly Available Specification does not replace, contradict or supplement any of the World Wide Web Consortium (W3C) guidelines or specifications. This PAS is vendorneutral and productneutral.”
- p. 3: “The Web will only be truly accessible when all of the following work in harmony, using the relevant W3C guidelines and specifications” (e.g., developers use WCAG and accessible “non-W3C formats”); mentions WCAG in context of authoring tools, plus UAAG and operating systems.
- p. 4: “The recommends… as essential requirements… the application of W3C guidelines and specifications testing conformance to ”
- p. 5: The only mention of a standards body under “Normative references” (§2) is the W3C.
Also, Annex A.1, p. 36, states that a low-vision person “might enlarge text in the browser with high contrast and use Windows’ colour preferences.” Oh? The Foreword (p. iv) states that “eneric terms are used in preference to brand names to ensure impartiality.”
PDF & Flash
§22.214.171.124, p. 24: “As PDF is not a W3C technology, technically its use does not uphold WCAG.” Actually, Checkpoint 11.1 merely requires developers to “se W3C technologies when they are available and appropriate for a task.” W3C technologies are widely available, but in at least 14 defined use cases, (X)HTML+CSS is not appropriate and PDF is, meaning you are in fact complying with WCAG in those cases.
PAS 78 also somewhat confuses Acrobat version level with PDF version level. It does, however, mention PDF/UA; apparently because it isn’t a W3C Working Group, no hyperlink is provided.
§126.96.36.199 on Flash is so hard to understand it needs a complete rewrite. [“From version 6 Flash Player and the authoring tool (Adobe Flash MX), functionality for creating more accessible content was included.”]
Captioning (and, inevitably, “subtitling”)
I was pleased to see, at §5.4 (p. 15), that “Deaf and hardofhearing people for whom English is their first language… will benefit from captioning of any audio materials.” Just captioning, not “subtitling,” which is incorrectly used to mean “captioning” and “subtitling” in only one English-speaking place on earth, the British Isles.
Later, §188.8.131.52 (p. 25) states that accessibility “is usually achieved using captions or subtitles and audio descriptions of the visual track” (followed by a poor definition of audio description). As written, a Web site can subtitle its videos into French and meet the criterion. Captioning is not subtitling even if you and all your friends think it is. (The lengthy and circuitous glossary defines neither term.)
The rest of §5.4 is worrisome. It appears to require “the provision of material in British Sign Language.” Also on that topic, Annex A.3, p. 36, claims that converting a page to symbols for people with learning disability may not be a good idea because “t is a language that has to be , in a similar way to sign language.” Sign languages are natural human languages and symbol systems like Blissymbols aren’t, full stop.
There is an unwarranted vote of confidence for the highly questionable vapourware technology of “signing avatars.” The British will go to any lengths to avoid captioning, from calling it something else to recommending technologies that don’t exist yet.
The specification puts a lot of emphasis on testing and I agree with nearly everything. The “Suggested questions for suppliers” (Annex C, p. 38) are very strong indeed. (Just copy and paste!) The questions for usability testers (Annex F, p. 44) are much weaker and are rather repetitive, and the last item on p. 46 isn’t even a question; it’s more of a manifesto.
However, §8.1.2 (p. 26) is a bit aggressive in saying that everyone “should ensure that those testing the Website are different from those developing it.” Well, no. We always test our own sites. Some of us are people with disabilities, and some of the tests we run can conclusively diagnose certain accessibility failures.
Annex A.1 states: “Because there are three main types of colour blindness it is unlikely that all problems would arise in user testing.” I don’t think that’s true as written. Since the majority of colour-deficient people have red/green confusion and a much smaller number have blue/green confusion, it is quite possible to test for accessibility with the majority of this audience in one go. I find that colour deficiency, which is a bit involved to learn but easy to understand once you get there, is consistently mishandled in accessibility guidelines. This seems to be another such case.
Where the hell is my book?
The Bibliography is questionable, listing “Useful websites” like Microsoft and the loveliest site on the Web, Useit.com.
It also lists two books on Web accessibility but does not list mine, even though mine is, by popular consensus, the best of the lot and is the only one freely available online.
Other than that, great spec.