WCAG Samurai Errata Review

Context of this review

A few weeks ago Joe Clark emailed me asking if I’d be interested in doing an independent review of the WCAG Samurai’s errata, i.e. corrections for, and extensions to, the Web Content Accessibility Guidelines 1.0. (WCAG1.)

I said yes, and last Friday they dropped into my inbox. Unfortunately I only picked up my work email on Monday, but a couple of late nights later here we are. That’s enough about me, on with the review.

Please note that for this to make any sense, you’ll need to know about the WCAG guidelines and the errata. Also, I will probably say thing like ‘we usually’ a few times, in which case I’m referring to the team at Nomensa, where we regularly debate accessibility minutia to review our practices.

Summary

Overall, there is much more to agree with than disagree with, and much of it is well over due. The ‘until user agent’ checkpoints are gone or settled, and there is an explicit requirement to actually learn HTML properly.

Using the errata in conjunction with the guidelines makes it much clearer how you would ‘comply’, using language like ‘ban’ and ‘require’. How people deal with non-HTML content like Multimedia and PDFs is also very clear, with explicit advice and exceptions for both.

There is only one point I definitely disagree with (relative units), but there are a few revisions that could cause issues for people in the short term. For example, skips links are gone. Although the function that skip links enable can be done on the user-agent side, currently few people using only a keyboard (but without a screen reader) know how.

I don’t think it is wrong to revise the guidelines in this way, assuming that there is some pressure on people producing user-agents to make appropriate updates.

The main limitations are really based on the source material.

The errata have not tried to cover all online formats, there is the underlying assumption (from WCAG 1) that you are building a site with HTML/CSS/JavaScript, with perhaps some Flash or PDFs.

There is bound to be some controversy comparing WCAG1+Samurai to WCAG2, however, the accepted technology focused of the errata gives it an immediate advantage for those creating standard web sites. For those using other technologies, WCAG2 is probably easier. They are not mutually exclusive.

The second limitation is that fact that these are errata, rather than a ‘WCAG 1.5′. Unless a complete set of revised guidelines is published, I doubt people new to accessibility will learn WCAG 1.0, then apply themselves to learning how the errata fit in. For those of us who have been dealing with WCAG 1 for years, you can read and understand the errata immediately. But for those new to the field, I have a strong suspicion that unless there is one, updated, document to put in front of them, it’s success will be limited to those familiar with the original. Whether that is really a criticism is entirely down to your point of view.

I suspect this would be a very difficult thing to achieve, hinted at in the overview where it states:

these errata are published as review and criticism of
WCAG 1.0 under the fair-dealing provisions of Canadian copyright law.
They are not a derivative work and they are not an “integration of
errata.

An extension of being limited by the original document is that the advice laid out in the errata is as unintelligible to the new comer as the original guidelines. I’m entirely guilty of this myself, but this review is squarely aimed at those familiar with both WCAG and the errata.

Agreements - the easily accepted

The points at which I clapped my hand with joy were:

Multimedia (Guideline 1)

Crystal clear advice such as:

Videos may not play without user activation. Your page or site may
not automatically play videos upon loading the page.

As part of developing best practice advice for clients over the years, this is just the sort of thing we would like to say, but didn’t have the backing to be so forthright.

Another aspect that I think works well is the requirements for transcription, where:

Large sites with significant budgets and resources must
publish transcripts to coincide with release of the podcast.

There is no such requirement for small sites with small
budgets (including personal blogs), but there cannot be an
unreasonable delay. (We do not define large or small or what
is or is not reasonable.)

You might well wonder what significant budget is defined as. I think the beauty of this approach is that it is left up to the organsation. If there is a dispute, the courts are much better placed to make that decision than accessibility experts. (Obvious caveat: I am not a lawyer.) This has to be far better than a blanket proclamation either way.

Removing Priority 3 checkpoints

With a couple of exceptions noted below, this is a good thing. In audits and consultancy where we help clients meet the guidelines, Priority 2 checkpoints were always the hard ones to meet (often because their CMSs was crap). The Priority 3 checks were either redundant, trivial to do (e.g. skip links), or untestable.

Relying on colour (Guideline 2)

WCAG confused an (old) testing method (using a black and white screen) with the actual guideline. The errata comment on that is Web accessibility is about people with disabilities, not their equipment.The guidelines for developers on colour contrast are quite clear, as I would expect from having read Joe’s book.

Explicit inclusion of semantics

Although it doesn’t mention specific elements, it includes a clear call to learn HTML. Properly.

The only issue I can see with this is the lack of examples, or a clear “you must use these for accessibility”. It is a tricky one to enforce. Some things are obvious, such as headings, lists and quotes (which were in WCAG 1). Mentioned elsewhere in the errata is hreflang, which is one of the most underused HTML elements ever, but deemed useful here.

Most developers think they know HTML, but few have used the cite or hreflang attributes. Some people may be surprised by what we could bring up in audits based on these checkpoints. However, wrapping all the ‘use HTML properly’ checkpoints into one section makes it much clearer and easier to deal with.

Scripting (Guideline 6)

The errata don’t have lots to say on scripting, this is the main aspect:

Do not provide alternative presentations or alternate pages (Checkpoint 6.5). Make the original; page accessible.

This leaves the checkpoint stating that pages should work without scripts in place, but removes the option to create an alternative (which conflicts with the other checkpoints anyway).

Controversial clarifications

Some things have either been long running debates, or swept under the carpet.

Valid HTML

Making valid HTML a requirement for accessibility makes my life as an accessibility and web standards guy much easier. Yes, you can have valid and inaccessible pages, but getting people to use and test (themselves) for validity has helped massively in gaining traction. Especially when combined with moving people onto CSS based methods, a must for practically implementing accessible sites.

One question though. If you require a valid page when actually rendered to the reader of the page, do IE’s conditional comments bypass that? For practical reasons I would hope so.

Adverts are your problem

Site owners will often dawdle without action over adverts that they include. If site owners are definitely responsible, they might actually require the advertisers to clean up their act.

Don’t use tabindex or accesskeys

At last. They can be put to bed (in their current form).

Disagreements, or just short term pain?

Relative units (Guideline 3)

This was the one I do really disagree with, although I would certainly accept that WCAG 1 needs updating.

You may use any defined units for text sizing, layout, or other purposes. The difference between relative and absolute units is immaterial to these errata. (px, by specification, was and is a relative unit.) Use of px as a unit to size text is explicitly permitted.

So many sites could become inaccessible to people with visual impairments if you let pixel specified layouts and fonts reign. There are two main strands:

1. Lack of effective zooming in user-agents.
2. If developers are not made to think about implementing relative units, many sites will become unusable when font sizes or layouts are manipulated by the user.

On the first point you could say that Opera has a decent zoom, if people need one they should use Opera. However, there are a lot of people on government and corporate networks trapped on Internet Explorer (5.5), who have no option of using another browser. If the argument then is that the employers are in the wrong here, that is probably correct, but it would still cause end users problems.

The second point is more important long term: If developers don’t allow for flexibility (e.g. using the bulletproofing concepts coined by Dan Cederholm) people who do use browser controls will find a lot of sites that are unreadable and/or unusable. I come across fixed width/height elements causing issues regularly.

The whole issue of resizing is complicated now, and is only going to get more complex as higher resolutions screens become more popular. The errata is right to point out that the pixel is a relative unit, but since browsers currently treat it as fixed (by the user’s resolution) it can and does cause people problems when either they can’t increase the text size, or when they do.

Dare I mention that the WCAG 2 process actually took my comments on board? (Well, partially.) I have a feeling that the best approach is really a testing process rather than a guideline, as there are too many variables.

Titles on links are enough to identify pop-ups (Guideline 10)

Do not cause pop-ups or other windows to appear and do not change the current window without informing the user. (Plain text is the preferred method of informing the user. The title attribute on a hyperlink a element can suffice.)

I could be biased, as I’ve been saying for 5 years that title isn’t enough. However, the main reason I’ve been saying that is if you must inform the user (and you do, I’ve seen the confusion ensue when you don’t), then the method must work for all.

People who don’t use a mouse are the main audience, I don’t know how to get at a title attribute via the keyboard. If you use a screen reader, you theoretically can, but it tends to be at the expense of the actual link text due to mis-use of title by CMSs.

The text is ideally made part of the link, although if you use a lists of links it would be sufficient to mention about new windows in text above the list.

Images for text

The guideline preventing the use of text in images is repealed:

There is no prohibition against using pictures of text (”images to represent text”) if correct text equivalents are provided.

Traditionally our advice has been not to use images for text, although above a certain size (we settled on a fairly arbitrary figure of 16px) it would be ok, because anyone needing more magnification than that should have a full screen magnifier.

Even with the best screen magnifier, small text within images can cause issue for people with moderate visual impairments.

Deprecating the q element

You do not have to use the q element; you do have to indicate inline quotations, as by the use of quotation marks or figure dashes.

This may be more of a content issue that specifically an accessibility one, but I quite like the ability to add a cite attribute and use it to link through to the source. I’m also slightly surprised that the internationalisation aspects don’t appeal either.

Keywords first

The WCAG guideline is to Place distinguishing information at the beginning of headings, paragraphs, lists, etc., which the errata removes.

I have seen this issue in testing: A page had many links starting “Chapter X: keywords”. Each screen reader user gave up by the 3rd item, skipping elsewhere in the page, even though that was the correct place to be looking. It also caused issues for those with cognitive issues (specifically dyslexia that I’ve noted), who would skim over the text and move on.

Another common example is including the whole URL in a link (for misguided accessibility reasons), so each link starts “http://www”, quite frustrating to skim.

Skip links

Skip links have gone with the rest of the Priority 3 checkpoints, and although replacements are on the way (WAI-ARIA), there is some time to go before they are recommended, let alone mainstream.

How organisations might react

You have to wonder how it will be received. It has to be said that it will muddy the waters somewhat. We already have enough trouble explaining that a national scheme such as See It Right are merely a re-badged version of WCAG 1.0, without having to explain the difference between WCAG 1.0, WCAG+Samurai and WCAG 2.0.

If you take WCAG 2 out of the equation, then adding these errata would be a no-brainer. Even with WCAG 2, previous versions of the draft stated that it did not supersede WCAG 1, and overall I suspect these sets of guidelines are not mutually exclusive. I suspect that once the HTML techniques come out, they will be fairly similar to the combined WCAG+Samurai.

Curiosities and clarifications

Since I’ve had no part of the process until this point, a few thing occurred to me when reading through that I’m curious about:

• Do some technologies actually make use of hreflang at the moment?
• Are previously entered values suitable as default characters for inputs?
• Surely it would be difficult or impossible to suitably tag some of the PDF examples given? (E.g. Maths equations.)
• Allowing custom DTDs, could put the thought into people’s heads of developing a deliberately inaccessible DTDs/schemas!

About me

Alastair Campbell, Director of User Experience at Nomensa.

I have been working with the WCAG 1 guidelines since 2001, building sites to be accessible, conducting audits on client sites, and comparing the results to actual usability testing with people with disabilities. Google alastc or alastairc for more, since the results for my name generally get swamped by some political guy.

To be clear, I don’t know more than anyone else at this stage. In fact, given the mystery surrounding the project I’ve considered that it could be Joe creating the errata alone, or 10 famous names that didn’t want to be seen as criticising the W3C. Either is possible as far as I know, I’ve only met Joe Clark once, at a UK government event last year.