This is an old, incomplete draft.
It is not being maintained.

OUT-DATED DRAFT - Myths and Misconceptions of WCAG 2.0.

This is an internal draft from the WCAG Working Group. The content is not ready for review or distribution.

Myth No. 1: Use of Color on a Page is Bad: FALSE

It is good to use color on a web page, and it is encouraged. It adds vibrancy, and can make pages easier to understand. Use of different color backgrounds can also separate areas to make them standout as different from each other.

Myth No. 2: It is Bad to Encode Information with Color: FALSE

Again, the use of color to present information can be very effective for those who can see color and make pages easier to understand quickly or by people who have cognitive language or learning disabilities.

What is bad is to encode information ONLY in color. If information is encoded in color alone, then individuals who have different types of color blindness may be unable to perceive that information.

For example, if things that are ‘safe’ are in green and things that are ‘unsafe’ are in red, a person with red/green color blindness cannot distinguish them.

If things that are dangerous are marked with a red triangle and things that are safe are marked with a green circle, they are distinguishable both by individuals who have red/green blindness (based on their shape) and by people who see color who would see both the shape and the color.

One could also use the words safe and unsafe, coloring the unsafe red and the safe green. However, it would be better to use the words ‘danger’ and ‘safe’ so that those without color vision can more easily see (and hear) the difference (because the words ‘danger’ and ‘safe’ look and sound much more differently than ‘safe’ and ‘unsafe’) .

NOTE: if an image is used it would of course need to also have a text alternative

Myth No. 3: Red and Pink are Different Colors; FALSE

In WCAG, when we say color, we refer to hue. Red and pink are the same hue with different lightness.

This is important because coding things in dark red and light green would be differentiable, even to someone with color blindness, in the same way dark red and light pink can be differentiated even when presented in black and white.

So something coded in dark red and light green would not be considered to be encoded in color alone since they are also encoded in lightness. Note that information that is presented in this way must ALSO be presented in a fashion that is able to be detected by assistive technologies and other user agents (must be programmatically determinable).

Myth No. 4: Layout Tables Are Not Allowed in WCAG 2.0; FALSE

Layout tables can be used in WCAG as long as any information which is presented through the positioning of the elements on screen is also available in a fashion which can be programmatically determined (e.g., determined by assisted technologies used by individuals who cannot see the layout). It is best practice however to separate layout and content, for example, by using style sheets to achieve the layout.

Myth No. 5: If You Fail One of the WCAG Techniques, Then You Fail WCAG 2.0; FALSE

The techniques in WCAG are just that. They are techniques, ideas, or ways to make pages more accessible. Techniques are never required. Repeating, TECHNIQUES ARE NEVER REQUIRED IN ORDER TO MEET WCAG. They are just one way of making pages more accessible. There are other ways as well that may not yet have been documented by the WCAG working group.

Myth No. 6: Sufficient Techniques Must be Met in Order to Pass WCAG; FALSE

TECHNIQUES ARE NEVER REQUIRED IN ORDER TO MEET WCAG. This includes techniques that are listed as “sufficient techniques” in the How To Meet WCAG 2.0 document.

Techniques that are labeled as “sufficient techniques” are simply techniques that the WCAG working group has determined would be sufficient to meet a particular success criteria. That means that you can use them with confidence to meet a particular success criteria.

However, you do not have to use these techniques. If you know of other techniques that would, in fact, meet a success criteria, then those techniques can be used instead. You must of course do something that meets each of the success criteria.

'The only thing that you must do to meet WCAG is to meet the success criteria and conformance requirements in WCAG.' Nothing else in any of the other WCAG support documents is required.

Myth No. 7: When It Says must in a Technique You Must Do It: SORT OF, BUT NOT REALLY

If it says “must” in a technique, (including the test at the bottom) it means that you must do that in order to successfully implement that particular technique. But since no technique is required, any requirement in a technique is limited to successful use of that technique and is not a requirement for meeting WCAG 2.0. The only things needed to meet WCAG 2.0 are the success criteria and conformance requirements in WCAG 2.0.

Myth No. 8: Pages Must Work with CSS to Meet WCAG 2.0: FALSE

CSS is a very powerful technique for creating web pages that are accessible to many types of disabilities. Using CSS even allows you to implement many techniques that go beyond WCAG 2.0. However, using CSS is only one way of meeting WCAG 2.0. WCAG 2.0 can also be met with other techniques and technologies which do not use CSS.

Myth No. 9: Pages With JavaScript Cannot Meet WCAG 2.0: FALSE

WCAG 2.0 was designed to allow many new modern technologies to be used and still provide accessibility. Pages with JavaScript can be made to conform to WCAG 2.0. It is also possible to write pages with JavaScript using the JavaScript in a way that would make the pages not conform. It is also possible to create a page using only HTML which do not conform.

Myth No. 10: A Text-Only Page Can Be Used to Meet WCAG 2.0: TRUE, BUT NOT RECOMMENDED

First, there are different definitions for a “text-only page”. An HTML page which is composed of nothing but text and links (that is, no images or other technologies are embedded on the page), is often referred to as a text-only page. For individuals who can only use a screen reader (particularly those who are not adept at using screen readers), a page which is crafted specifically to read clearly and understandably when read aloud could, in fact, be a very accessible form of the page. However, the use of “text-only alternative pages” can cause problems and are less desirable for a number of reasons.

First, very few people actually put all of the same information on a text-only page that was on the original page. Sometimes they only put the text that was on the original page on the alternate ‘text only’ page. Other times they will put the text and some, but not all, of the information which is presented visually. Often they don’t even realize how much information is presented visually, and will omit some. Any of these would cause the page to fail the "accessible alternative page" criterion.
A second critical reason it is discouraged is that, unless the two pages are generated automatically from a common data source on-demand, the two pages rarely are kept in sync. The text-only page usually is updated later, much later, or not at all after the original page is changed. This also would cause the page to fail the "accessible alternative page" criterion.
Many individuals who need assistive technologies to access a page have partial or complete sight. As a result, they could benefit from all of the visually presented information on the page. At the same time, they need the page to work with their assistive technology. Providing an alternate accessible page without the visual/graphic information means that this user has to choose between two pages, both of which have part of the information they would like to view, rather than having a single accessible page with all of it.
With rare exception it is not necessary to provide a separate text-only page or even an alternate accessible page. It is possible to create very dynamic and visually pleasing pages that are completely accessible. If an alternate fixed or printable version of the page is desired (for example, a PDF version of the page) this could be provided as the “printable alternative” page to the accessible primary page rather than having the PDF be the primary and the accessible page be the alternate.

NOTE: Technically an plain text document could be a 'text only page' and meet WCAG if it is very simple. But mostly when people talk about text-only pages, they mean HTML pages that do not have any graphics or other non-text content on them.

Myth No. 11: If a Page Meets WCAG 2.0 it is “accessible”: NOT REALLY

WCAG 2.0 is an accessibility standard with three levels of accessibility. Conforming to each successive level will make pages more accessible to more people in more situations. However, even if you meet all three levels of WCAG 2.0, there are still people who will not be able to use the page and others who may be able to use the page for some tasks or in some situations, but will not be able to use it in others.

In addition to the “sufficient” techniques used for conformance, WCAG also lists a large number of “advisory” techniques which can be used to make the page accessible to still more people. Techniques in the advisory category, however, are often techniques which are not testable or which only apply in certain circumstances.

Even if you implemented all of the applicable sufficient and advisory techniques there would still be individuals who would not be able to use the websites. To declare a website “accessible” in the absolute, therefore, is not possible. It is also not possible to create buildings or signs or anything else that is “absolutely accessible”.

This myth is not called “false”, however, because we often refer to buildings as being “accessible” if they meet the prevailing standards for a particular country or technology. Similarly, for web pages we often refer to a page as being “accessible” if it meets the appropriate set of web accessibility guidelines. However, to be accurate we should say that the site “meets WCAG 2.0 accessibility standards at Level A or AA or AAA”. Even saying that a website is “accessible” because it meets WCAG 2.0 is ambiguous because there are 3 levels of accessibility to WCAG 2.0.

Myth No. 12: Images of Text Cannot Be Used, CSS Must Always Be Used to Style Text: FALSE

CSS is not supported by all technologies and cannot be used in many of them.
CSS also has limitations and cannot be used to render text in all desired appearances.

CSS is, therefore, not required

if the technology cannot support CSS, or
if the [desired] visual presentation cannot be achieved using CSS, or
if some other text formatting technology is used instead of CSS

At Level AA, there is a requirement that “If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: (Level AA)” So for level AA, if none of the exceptions are true then CSS or some other text formatting technology must be used (if they exist for the technology you are using) to format text rather than using an image of the text. But it only requires that text be used if it can be formatted properly. It does not require any particular technology including CSS be used.

Myth No. 13: The WCAG Guidelines Are About Access Using HTML or XHTML: FALSE

The guidelines were specifically written to support many different technologies. In fact, there are techniques documented by the working group for meeting WCAG 2.0 with PDF, Flash, Silverlight, JavaScript, and other techniques and technologies will appear as techniques are documented. Also remember that it is possible to meet WCAG 2.0 with techniques and technologies that are not yet documented by WCAG 2.0 working group.

Myth No. 14: WCAG 2.0 is Primarily About Creating Accessible Pages Using W3C Technologies: FALSE

The WCAG 2.0 was written specifically to work across all technologies. Being a good citizen, the W3C made sure that the techniques for meeting WCAG for its own technologies were among the first to be documented. However, JavaScript, MPEG, JPEG, ADI, and many other technologies were also among the first. The working group has also worked diligently with other creators of web technologies to ensure that techniques for their technologies were also documented and included in the WCAG 2.0 support documents as “sufficient” techniques, etc. as quickly as they were described and provided to the working group for consideration.