WCAG Samurai Errata for Web Content Accessibility Guidelines (WCAG) 1.0

V1.0 of 26 February 2008

You may wish to read the introduction first. The following sections are organized according to the sections listed in Web Content Accessibility Guidelines 1.0, which we use as a base.

Special note about cognitive disabilities

These errata do not substantively correct WCAG 1’s provisions for cognitive disabilities. Compliance with WCAG+Samurai cannot be a claim of full accessibility to people with cognitive disabilities.

Guideline 1.
Provide equivalent alternatives to auditory and visual content

The central error in most discussions of text equivalents is a claim that a text equivalent “conveys essentially the same function or purpose” (WCAG 1) or “describes” the content. Such terminology misleads people into thinking they must write a long narrative about a simple picture: “This is an image of an arrow that is a link to the homepage.”

In addition, text equivalents can be evaluated only by human beings. Writing and appraising them is subjective. WCAG Samurai does not attempt to dictate your writing style.

WCAG Samurai redefines text equivalents as replacements for an image or other item.

• You must be able to substitute the text equivalent for the original item. When you do so, your page must still function and readers must not lose significant meaning.
• There may be no way to avoid loss of meaning when writing text equivalents for some works, like photographs and paintings. It would be pointless to define “significant meaning” in this context. Just as we empower you to write your own text equivalent, we empower you to rationally decide if the equivalent really is an equivalent.

General corrections to Guideline 1.1

• Providing a text equivalent “in element content” may apply solely to certain hypothetical iframes and, where usable, to SVG or Flash. Ordinary HTML pages have no method to provide a text equivalent “in element content.” The use of offscreen positioning to duplicate the words presented in a text-heavy image can be considered comparable and is permitted.
• You can leave a text equivalent blank – e.g., null alt text, alt="" (no space inside quotes) – if the text that immediately surrounds, precedes, or follows the image has the same function as a text equivalent.
• “[G]raphical representations of text” and “images to represent text” are pictures of text. There is no prohibition against using pictures of text if correct text equivalents are provided.
  • In HTML, use an alt text of exactly the same text (even if it contains more than one language).
  • Type samples or other languageless textual illustrations do not need to include all the text in the image and may use equivalents similar to alt="Sample of Verdana font showing letters and numbers". Images of text in which actual typography is of interest (e.g., the use of certain fonts or bold or italic within a word), or images of large blocks of text where the graphic design or copy-editing are of interest, need not include all the text but must explain the points of interest.
  • Symbols are not “graphical representations of text” unless they are actual pictures of text. Use those only if Unicode, or another declared character encoding, cannot represent your character. For example, do not use pictures of arrows in running text or attribute values; use a Unicode arrow character.
• “Applets” and “scripts” must be made intrinsically accessible, as by using JavaScript or Flash accessibility features. Do not use text equivalents for such intrinsically accessible applets. Ignore the WCAG reference to “programmatic objects.”
• If images must be used for list bullets, do so only using CSS, as with

  ul { list-style: url("arrow.gif") disc }

• PDF files published by the normal means (e.g., a simple hyperlink to the PDF) are not non-text information and do not need text equivalents.
• When linking directly to an image so that the image is viewed as a separate document unto itself with no markup, no text equivalent is possible or necessary. For example, linking to http://wcagsamurai.org/image.jpg does not require you to write a text equivalent.

What not to do

Do not use animated GIFs, ASCII art, frames, layout tables, spacers, or server-side imagemaps.

Charts and diagrams

• The ordinary text equivalent for a chart or diagram (e.g., alt) must explain the features of the chart or diagram that are relevant to the document and that would cause the document to be misunderstood if omitted.
• Extensively detailed charts or diagrams may be described using longdesc or in ordinary text, the latter of which can be positioned offscreen if desired.
• Do not publish or link to an original set of data as a pretended text equivalent. If proper text equivalents are provided, however, then additionally publishing or linking to original data is permitted.

Sounds and audio files

• Sounds may not play without user activation. Your page or site may not automatically play sounds upon loading.
• Sounds and dialogue in games and all other Web content, whether prerecorded or machine-generated, must be open- or closed-captioned (save for the exceptions listed below).
• Podcasts and other recordings consisting mainly of dialogue, speech, or interviews must be transcribed.
  • 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,” “small,” “significant,” or what is or is not “reasonable.”)
  • Recordings used as examples of spoken language (where the language itself or its use is the purpose of the recording, not the meaning of the words uttered), including language-learning sessions and linguistic field recordings, do not have to be transcribed.
• Podcasts and other recordings that are mainly musical, including DJ sets and music programming from broadcasters and Webcasters, do not need to be transcribed. However, set lists or lists of song titles and artists must be published shortly after publication of the podcast. (We do not define what “shortly after publication” means.)
• Podcasts and other recordings in languages other than the main language of the surrounding page do not need to be translated, as by dubbing. (If you provide 20 podcasts in one language but half of one episode of one podcast is in another language, you do not have to translate that portion.) Do not present a translation as a claimed method of accessibility for people with disabilities.
• Live broadcasts or Webcasts that are not recorded or archived do not have to be captioned or transcribed. Once recorded or archived, the normal provisions for recorded podcasts then apply. In particular, this means that streaming-audio services that play repeat broadcasts have to treat those repeats like any other recording.
• Internet telephony, voice or video instant messaging, relay services of all types, voice conversations during gaming, and other live speech and sign language are not Web content and do not have to be captioned or transcribed.

Video

• Videos may not play without user activation. Your page or site may not automatically play videos upon loading.
• All videos with a soundtrack must have open or closed captioning. (The correct term is “captioning,” not “subtitling”; subtitling is a translation. In English, use only “captioning.”) Silent movies need not be captioned, but the fact that there is no soundtrack must be explained, as on the page that links to or embeds the video.
• Videos that cannot be understood from the main soundtrack alone must have audio description, either open or closed. (The correct term is “audio description,” not “auditory description” as stated in WCAG 1 or “descriptive video” or “video description.” In English, use only “audio description.”) Videos with a soundtrack but no visual component (e.g., a continuous black screen) do not need audio description, but the fact that there is no visual component must be explained, as on the page that links to or embeds the video.
• Videos that are presented as examples of written, spoken, or sign language (where the language itself or its use is the purpose of the recording, not the meaning of the words), including language-learning sessions and linguistic field recordings, do not have to be captioned, transcribed, or described.
• Videos in languages other than the main language of the surrounding page do not need to be translated by subtitling or dubbing. (If you provide 20 videos in one language but half of one episode of one video is in another language, you do not have to translate that portion.)
  • This requirement includes sign-language videos, which also do not need to be translated. If, however, voice interpretation is provided or there is any kind of soundtrack, normal captioning requirements apply.
  • Do not present a translation as a claimed method of accessibility for people with disabilities.
• Screencasts (narrated slideshows) are equivalent to slow-motion video with regular-speed sound and have to be captioned.

Note that a separate transcript, either in plain text, HTML, or some other format, is not a substitute for captioning or audio description. A transcript may additionally be provided.

Guideline 2.
Don’t rely on colour alone

This guideline could be the single most misunderstood portion of WCAG 1, in part because it confuses actual human disability with computer equipment (and also doesn’t understand the disability correctly).

The purposes of this guideline are:

• To prevent the use of confusable colours in confusable ways. Preventing such use provides accessibility to people with the main colour deficiencies – protanopia, deuteranopia, and tritanopia.
• To avoid any references to items on a page using colour alone. Avoiding such references provides accessibility to the much smaller group of people with achromatopsia, who have little or no ability to distinguish colour, and to totally blind people.

The original WCAG guideline does not address colour combinations that are preferred by people with certain learning deficiencies. As with other WCAG 1.0 guidelines concerning learning disabilities, these errata do not attempt to correct this deficiency.

Ignore all references to “non-visual displays” or “monochrome displays.” Web accessibility is about people with disabilities, not their equipment. A “display” is not a person and does not need accessibility.

Confusable colours are typically those along the red and green axes (for the most common types of colour deficiency, protanopia and deuteranopia) and along the blue and green axes (for another type, tritanopia). The substitute colours that are seen by colour-deficient individuals are also confusable and tend toward beige, dull yellow, and brown. All those colours, and shades similar to them, are confusable colours.

• For actual content (in most cases, that means text), do not set one confusable colour on top of another. For example, do not set red type on a green or black background. There is no limitation on using confusable colours as design elements, nor is there a limitation on displaying areas of confusable colours next to each other (e.g., green type on a white background can sit alongside a solid red rectangle).
• Do not use colour as a sole method of indicating an item on a page, either in its markup or style or via reference. For example, do not return a form with errors indicated solely in red; use additional markup, like strong, and/or use additional text like an asterisk or a visual icon with text equivalent, and/or explain in words what the errors are and where they are located.

For maximum certainty in colour combinations for text and other content, use the Brewer Palette.

Guideline 3.
Use markup and stylesheets and do so properly

All Web pages that comply with WCAG+Samurai must have valid HTML and CSS.

• You may use any HTML document type except Frameset and any XHTML document type except Frameset (frames are prohibited); any published HTML revision (even HTML5 or a draft version of HTML5); or any XML document type, including your own custom-written XHTML document type.
• If the sole cause of invalidity on your HTML or XHTML page is the use of the embed tag, your page is deemed to comply if the video is made accessible by captioning or audio description, as required by the content. You are permitted to use a custom XHTML document type that includes embed (example).
• Any HTML or CSS inserted into a page by scripting or other methods must result in a valid page when actually rendered to the reader of the page. That also means that any conditional comments, or other programming or instructions that apply only in certain cases, must produce valid HTML and CSS when executed. The page as experienced by the visitor must use valid code.
• You may use any version of CSS.
• Your page will be deemed compliant even if a validator finds an error in the document if the validator itself is known to be in error on that specific topic.
• You may use any defined units for text sizing, layout, or other purposes. Your layout cannot trigger a violation of WCAG 1.0 or these errata.
  • You must test every site with significantly larger and significantly smaller type sizes than your intended default. No accessibility barriers must arise from such resizing. (We do not define “significantly larger” and “significantly smaller.”)
  • Liquid layouts are strongly preferred, but fixed layouts, or a mixture of fixed and elastic modules, may be used if testing shows no accessibility barriers.
  • The difference between relative and absolute units is immaterial to these errata.
    • The px unit, by specification, was and is a relative unit. Use of px as a unit to size text is explicitly permitted. However, each unit has its own implied semantics that must be followed. pt makes sense almost exclusively for printed pages, while px makes sense for extremely uncommon short texts that absolutely must be in a specified size (e.g., a legally mandated copyright warning).
• If your markup or scripting language or other code has no validator, the requirement to validate your code does not apply.

Keeping pages in compliance

As a reminder, not all pages on a site need to comply with WCAG+Samurai.

• After you become aware of invalid content on a page that attempts to comply with WCAG+Samurai, you must repair that invalid content within a reasonable time. If repairs are impossible, you must not claim compliance for that page.
• Pages that cannot be maintained in a valid state – including discussion forums in which members of the public may enter their own text and/or markup, or some Web applications – must not carry a claim of conformance with WCAG+Samurai.

Requirement to use HTML semantics

Not only must you use valid HTML in your documents, you must use valid and semantic HTML.

• You must use the most appropriate elements and attributes for your content, including headings, lists, and forms.
• For ambiguous cases, you must use the elements and attributes that most closely fit your content even if other authors would disagree. For example, you may mark up certain ambiguous items as a definition list even if other authors would use an unordered list, or you may use presentational elements like <b> or <i> when marking up content that is presentational rather than structural (e.g., when copying the presentation of a printed document to make a point about that presentation).
  • Other authors’ disagreement with your choices is not relevant to these errata.
  • This exemption applies to edge cases only, not to clear-cut items on a typical page. It is not a licence to mark up every item on a page as a paragraph if not everything really is a paragraph, or to use bold or italic formatting instead of correct heading elements, or to use simple paragraphs for list items, or to use <b> or <i> indiscriminately.
• 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.
• Do not use blockquote for indention.

Guideline 4.
Clarify natural-language usage

As a reminder, natural languages are used by humans to communicate with each other. Computer-programming languages of all kinds, even if they resemble natural languages or are derived from them, are not natural languages. Neither are methods of communication used by non-human animals.

• Identify the primary language of a document – preferably on the html tag, which must be included in XHTML documents (e.g., html lang="code" or html xml:lang="code"). Use published language codes (not limited to ISO 639-1).
• If a page is bilingual or multilingual, with each language having equal precedence, do not specify a primary language, as there is no “primary” language in that case. Specify languages as used on different parts of the page. For example, use <div> or <span> elements to wrap the text that is expressed in different respective languages; add language-code designations to that markup (e.g., <div lang=""> or <span lang="">).
• A page whose markup acts as nothing but a container for a video of sign language or a video or recording of spoken, written, or signed language must use the correct code for that language. A page written primarily in one language that includes a video or recording of another language must correctly identify that second language, if necessary by adding <div> or <span> elements.
• When an author knows that a hyperlink will deliver a site visitor to a page, video, or recording in another language, hreflang must be used with the language code for the linked page (e.g., hreflang="fr" on a link from an English-language page)
• Do not attempt to mark up language changes inside attribute values.
• Ignore WCAG references to search engines.

Guideline 5.
Create tables that transform gracefully

• Do not use tables for layout.
• The use of summary, <caption>, and abbreviations for headers is covered by Guideline 3. Use those elements and attributes if necessitated by your content. In specific, there is no requirement to use the summary attribute on every table.
  • You may use any applicable method of introducing and explaining tables, including summary, <caption>, table headers, ordinary headings (<h1> through <h6>), and plain text.

Guideline 6.
Ensure that pages featuring new technologies transform gracefully

• Do not provide alternative presentations or alternate pages (Checkpoint 6.5). Make the original page accessible. In particular, this requires you to use JavaScript or other scripting in a way that is intrinsically accessible. You are not required to create a single page that works exactly the same with and without scripting, nor are you required to create one page with scripting and another without it.
• A page that uses digital-rights management or copy protection of any kind cannot be claimed to comply with WCAG+Samurai, as its compatibility with adaptive technology and future technologies cannot be independently proven.

Guideline 7.
Ensure user control of time-sensitive content changes

• Do not cause flickering, flashing, or blinking. Advertisements, including advertisements served by a third party on a page you control, are covered by this guideline. They too may not cause flickering, flashing, or blinking.
• “Moving content,” scrolling, crawling, or animation cannot play automatically, even in advertisements. The site visitor must choose to experience such moving content (either by site-wide preference, by explicitly clicking or selecting an on switch, or by another means that is accessible to users with disabilities).
  • The site visitor must be able to pause or stop moving content. Note that there are no exceptions.
  • The site visitor must be able to change the speed of moving content, unless speed changes are unreasonably difficult to implement. (If you must make a choice due to limited engineering resources, a speed change that slows down moving content is more important to implement than one that speeds up moving content.)
• When server redirects are impossible (e.g., because the overseer of a site cannot modify an .htaccess file or equivalent), a meta refresh of 0 seconds is permitted as a way to achieve a redirect.
• blink and marquee may not be used, even in a custom XHTML document type.

Guideline 8.
Ensure direct accessibility of embedded user interfaces

[No errata given.]

Guideline 9.
Design for device-independence

• Do not use server-side imagemaps.
• Do not create a custom tab order using tabindex. Do not use tabindex.
• Do not create custom keyboard controls using accesskey. Do not use accesskey.

Guideline 10.
Use interim solutions

• 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 strongly preferred method of informing the user. Use of any other method must be reserved for cases where plain text is unreasonably difficult or impossible.
  • The title attribute on a hyperlink <a> element can suffice in the unique case of legacy pages that are unreasonably difficult to update. It is not sufficient in newly-created pages or other circumstances.
• Do not provide linear text alternatives. Use correct document semantics; do not use tables for layout.
• Do not add default, placeholding characters in edit boxes and text areas, even if those characters are removed by scripting when the field receives focus, unless:
  • the text is included after processing the user’s input (e.g., after verifying that a desired user ID is unavailable, a site may propose a new one)
  • the semantics of the document naturally would include such characters (e.g., a promotional offer available only to residents of a certain country may pre-fill the name of that country)
  • the characters were previously entered by the user (e.g., in the case of refining a previous search)
• Do not add non-link, printable characters (surrounded by spaces or not) between adjacent links unless the semantics of the document naturally would include such characters.

Guideline 11.
Use W3C technologies and guidelines

• Use XHTML or HTML for documents consisting primarily of text and/or graphics. There is no requirement to use the latest versions of HTML or XHTML. HTML variations developed outside the W3C are permitted if adequately defined. Custom XHTML document types are permitted.
• Use CSS as the primary means of controlling presentation in XHTML and HTML documents.
• Flash, JavaScript, and other “interactive” technologies are specifically permitted, but must follow published accessibility guidelines in all cases.
• Deprecated features, including deprecated elements and attributes, may be used if no reasonable alternative exists.
• PDF may be used only for certain document types. All PDFs must be tagged, using appropriate semantics for the document. (In other words, a document in which all text is tagged as Para does not comply if not all that text really is a paragraph.)
• Do not create alternate pages. Make the page itself accessible.

Guideline 12.
Provide context and orientation information

• Do not use frames. (You may use iframes.)
• There is no requirement to provide a sitemap or table of contents unless the site cannot be understood or navigated without it.
• Do not place distinguishing information at the beginning of headings, paragraphs, lists, etc. unless it is significantly harder to understand the document without it. (We do not define “significantly harder.”)
• Do not use ASCII art.
• Hidden structural information (e.g., heading elements positioned offscreen) is permitted when document semantics warrant it.