Introduction

Samurai errata for Web Content Accessibility Guidelines (WCAG) 1.0

This is an introduction to the errata (corrections) for the Web Content Accessibility Guidelines 1.0 (WCAG 1). The errata are published by, and can be attributed to, the WCAG Samurai, an independent group of developers convened in 2006.

Where do I find the full errata document?

It’s available as of 26 February 2008. There are also two supplementary documents – one on the Brewer palette for colour deficiency and another on PDF.

What about WCAG 2?

These errata do not cover WCAG 2.0 in any respect. The WCAG Samurai errata are published as an alternative to WCAG 2. You may comply with WCAG 2, or with these errata, or with neither, but not with both at once.

Is this the final version?

Probably. The WCAG Samurai errata are now frozen at Version 1.0 for the foreseeable future. We are not willing to declare up front that we will or will not publish revisions. We will see how it goes. In particular, we will correct minor errors, or even some major ones. A difference of opinion is not an error in this context, as the entire point of these errata is an articulation of one group’s opinion.

Easy summary

Here’s a quick summary of the changes we’ve made to WCAG 1. (If you want to comply with WCAG+Samurai, you have to use the full details in the appropriate sections, not this summary, which is provided here for convenience.)

Just like in the real world, we assume you’re using HTML and CSS nearly all the time and JavaScript some of the time. We do not assume an unrealized future in which Flash, Silverlight, or other technologies are the main way to deliver Web pages.
We ban and we require: We don’t mess around with imprecise terms like “avoid” and “until user agents,” whose published definitions are misunderstood or ignored. Instead, you either may or may not apply a guideline. We use terms like “delete,” “ignore,” “not required,” “do not have to use,” and “do not use” on the one hand and “must” on the other.
No to Priority 3: Not only do you not have to comply with any Priority 3 guidelines, most of which are unworkable, you must not comply with them.
Yes to Priorities 1 and 2: You must comply with Priority 1 and 2 guidelines, as corrected by the Samurai. Among other things, this means you must have valid code in nearly every case.
No new guidelines for cognitive disabilities: WCAG 1 and 2 are both inadequate to address the needs of people with cognitive disabilities like dyslexia (though that is only one of many such disabilities, which often have conflicting needs). We couldn’t bring ourselves to delete the only guideline below Priority 3 that attempts to address cognitive disabilities (“Use the clearest and simplest language”), but we also haven’t devised a full suite of new guidelines. Nobody else has, either; it requires considerably more research and, importantly, user testing. Nor do we trust much of what we’ve read from the claimed experts in the field. We are leaving WCAG 1 almost exactly as it is on this subject. Separately, we require that compliance with WCAG+Samurai cannot be a claim of full accessibility to people with cognitive disabilities.
Tables for layout and frames are banned and all guidelines relating to tables for layout and frames are deleted. You may still use <iframe>.
Goodbye, <noscript>: Scripts and “applets” (which we would now understand as being Ajax and Flash most of the time) must be directly accessible. Not only may you no longer insert boilerplate content into the <noscript> element, that element must not be used.
We ban most PDFs: PDFs that should be HTML are banned unless they are accompanied by HTML. All other PDFs have to be tagged.
Goodbye, 20th-century relics: Instead of worrying about how to make holdovers from the late 20th century accessible, we simply ban unnecessary artifacts like ASCII art.
We’re more serious about multimedia than anyone else: Nearly all your videos with soundtracks must have captioning, most or all your videos must have audio description (depending on content), you have to transcribe dialogue-heavy podcasts (but not music podcasts), and you can’t use text files or HTML as substitutes for captioning or audio description.

How can I comply with the errata?

The first thing to understand is that you do not have to comply with these errata. The WCAG Samurai errata are an optional addition to WCAG 1, which we use as a base. You start by reading and understanding WCAG 1, then you read these errata as a correction to WCAG 1.

The errata tell you which parts of WCAG 1 you must ignore and which parts are incorrect. It tells you the proper modern methods by which you can comply with WCAG 1. As such, the errata pick and choose from the full range of WCAG 1. But you may not pick and choose from these errata. You have to comply with everything at once, as long as your document contains content that applies to a guideline.

You do not have to claim to comply with the WCAG Samurai errata even if you actually do comply. But if you wish to make that claim, you have to clearly say so. We do not dictate the exact terms you must use, but some examples are:

This site conforms to WCAG 1.0 as corrected by the WCAG Samurai errata.
Our site is built to comply with WCAG+Samurai.
We meet accessibility guidelines and we conform to the WCAG Samurai errata.

If only a few pages on a site comply, you must limit your statement to those pages. If only a few pages on a site do not comply, you must state the pages that do not comply.

Here are examples of terminology you cannot use:

We comply with most of WCAG (as corrected). [You didn’t specifically name the WCAG Samurai.]
Most pages of this site meet the requirements of WCAG 1.0 and WCAG Samurai. [You have to specifically cite which pages do not comply.]

Why we developed the Samurai in a closed process

Because the ostensibly open process of the W3C actually isn’t open: It’s dominated by multinationals; the opinions of everyone other than invited experts can be and are ignored; invited-expert status has been refused or revoked; the Working Group can claim that “consensus” has been reached even in the face of unresolved internal disagreement; the process is itself inaccessible to people with disabilities, like deaf people; WCAG Working Group chairs have acted like bullies.

The “open” W3C process simply didn’t work. We tried something else.

Implications of HTML semantics

To comply with WCAG+Samurai, you have to meet all Priority 1 and 2 guidelines, as corrected. That includes Guideline 3.2, which requires valid code (“documents that validate to published formal grammars”). We know from experience that a document that is valid HTML may still be inaccessible. The classic example is a page that uses tables for layout. A more relevant example is a page that has valid HTML but poor semantics (e.g., every block of text is marked up as a paragraph p, even if the text is really a list or a heading). We cannot really criticize the W3C for omitting document semantics when WCAG 1.0 was written in the late 1990s, but we must correct that omission now.

Under WCAG+Samurai, not only must you write valid HTML documents (with valid CSS), you must use the correct semantics for your content. We know that some content is ambiguous and sometimes you must approximate. (Should a segment of text use a definition list or an unordered list? Should a phrase use <strong> or just bold?) Edge cases like these are not sufficient to disqualify a claim of compliance with WCAG+Samurai because, across the Web, the correct semantics for most content is not in dispute.

Since we are requiring valid code, many WCAG 1 guidelines become redundant or are too restrictive. In particular, in the course of eliminating a requirement to comply with Priority 3, a few of its guidelines are subsumed under a requirement to use valid, semantic HTML.

You have to use <abbr> or <acronym>when your content necessitates it, but there are some provisos.
- You only have to use that markup if a human reader or adaptive technology would be likely to make a mistake or misunderstand the content (e.g., you don’t have to mark up “TV station” as “<abbr>TV</abbr> station”).
- Acronyms and abbreviations without expansions in real-world use (e.g., DVD) don’t have to be marked up.
- There is no foreseeable resolution of the dispute about the meanings of “abbreviation,” “acronym,” and “initialism,” and these errata deliberately do not join that discussion.
- There is no clear meaning of the WCAG guideline’s requirement to provide an expansion “in a document where [the abbreviation or acronym] first occurs,” because visitors may begin reading a document anywhere. Ignore this provision.
- We intend to clear up the actual accessibility problem to the extent HTML can; we are not interested in perpetuating a guideline that allows outsiders to claim your entire page is inaccessible because you made an intelligent choice about abbreviations and acronyms that the outsider disagrees with. You are not only empowered to make intelligent choices, you must.
- Nor are we interested in perpetuating an unequal playing field, in which authors must mark up extensive bits and pieces of documents but makers of adaptive technology, like screen readers, never have to update their own pronunciation dictionaries.
- Nor do we think that expecting a reader to look up the meaning of a specific abbreviation or acronym creates an accessibility barrier for many people with disabilities; in that context, those readers are on a level playing field with nondisabled readers.
In short, the abbreviation/acronym debate takes up too much time for the minuscule harm that is caused by even the most inaccessible and worst-marked-up documents.
We maintain the requirement to notate a change in document language, but that obviously implies that the original language must have been notated, too.
You have more than one way to explain the purpose of data tables (including the use of plain-text explanations), so there is no reason to require the use of the summary attribute, which, by specification, is hidden from anyone who can see, including some other persons with disabilities.
We exempt you from meeting certain guidelines for which no HTML semantics exist – like grouping related sections of a document, for which the only available option, <div>, has no actual meaning.
You must properly mark up forms, including the use of labels for all elements that require them.

Priority 3 guidelines to ignore

All of them. In particular:

Guideline 4.2: You don’t have to expand abbreviations and acronyms unless a person with a disability cannot understand the document without the expansion, as explained previously.
Guideline 4.1: You have to specify the language of a document in order to indicate a change in language. This guideline is a prerequisite for Guideline 4.3, which requires marking up a change in language. Correct language markup is required at all times, whether for base language or a change in language. There is, moreover, no way to mark up language changes in attributes, including alt texts, so do not attempt to do so.
Guideline 9.4: Do not attempt to create your own tab order. That is a job for a browser and adaptive technology.
Guideline 9.5: Don’t provide your own keyboard shortcuts. That is a job for a browser or adaptive technology.
Guidelines 10.4 and 10.5: Do not use placeholder text in forms. That is a job for a browser or adaptive technology. (Form fields may include text after processing – e.g., after verifying that a desired user ID is unavailable, a site may propose a new one – but such is not “placeholder” text. Or a site may store a cookie with already-entered information and repopulate form fields on request. That also is not “placeholder” text.)
Guideline 11.3: There is no practical way to comply with this guideline given that it implicitly requires authors to provide translations (not an accessibility issue) or different “content types” (e.g., duplicating an entire Web page in SVG, also not an accessibility issue). Not required.
Guideline 13.5: Not all sites or pages require navbars. This guideline applies only to sites that do require them. If your site uses navbars, do so consistently (e.g., do not arbitrarily switch from horizontal to vertical navbars within the same section of a site) and use correct markup (usually unordered list <ul>). If your site does not require a navbar, you are not obliged to include one.
Guideline 13.6: Not all sites or pages have “related links,” and the only HTML elements with relevant semantics work solely in forms (e.g., optgroup). The use of <link> inside <head> is not required.
Guideline 13.7: You don’t have to provide multiple kinds of search (not an accessibility issue). Not required.
Guideline 13.8: Headings are “distinguishing information,” and we know of no language that requires each paragraph to begin with “distinguishing information.” Not required. However, some kinds of Web pages, like glossaries, could meet this guideline by placing keywords first or early in a paragraph.
Guideline 13.9: Not required.
Guideline 13.10: Do not use ASCII art.
Guideline 14.2: Use the content you wish to use. You are not required to illustrate documents (nor, if you are a blind person, could you do so), which then would require text equivalents anyway.
Guideline 14.3: You may use any accessible “style” you wish, including styles that are not “consistent.”
Guideline 1.5: Not required.
Guideline 5.5: The summary attribute, by specification, cannot be manifested visually. HTML provides numerous ways of clarifying the purpose of tables (<caption>, summary, headers), and the same thing can also be done by explaining a table in plain text. When we say you must ignore this guideline, we mean you must ignore the requirement to use summary. It may still be the right method for some tables.
Guideline 5.6: Not required. Almost never necessary and poorly supported; the guideline as written requires abbreviations for all table headings.
Guideline 10.3: CSS layouts are more than adequately supported, and you may not use tables for layout.

General exception for instructional documents

Documents that aim to teach Web accessibility, including documents with intentionally incorrect markup or features that readers or students could correct, are exempt from WCAG+Samurai provided that the instructional intent is explained.

Peer reviews

We sent out an early version of these errata for independent, confidential peer review by two people, Gian Sampson-Wild and Alastair Campbell. You may read Gian’s review and Alastair’s review. The WCAG Samurai had no control over or foreknowledge of the contents of these reviews.

Copyright

We based the errata on the following original document from the W3C (with which we are unaffiliated):

Original document: Web Content Accessibility Guidelines 1.0.
Its status: “This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another documents. W3C’s role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and universality of the Web.”

We provided the references above to comply with the W3C’s standing copyright requests. Those references do not refer to the document you are presently reading.

These errata were developed independently of the W3C and make no statement or impression as to the positions, statements or actions of W3C. Frankly, we wouldn’t want to make any such statement, nor would we want them making such statements about us.

W3C™ is a trademark of the World Wide Web Consortium. So is HTML™, although “WCAG” is not.

Additionally, 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.”