Accessibility and the WCAG 2.0
- Damodar Chetty
- October 20, 2007


I have been working on a project for a government entity that insisted that any Web applications we developed had to meet W3C accessibility guidelines.

My instinctual reaction was 'its going to double our development and QA estimates, isn't it'. Next, it was 'so no Javascript?'. And, finally it was, 'So what does accessibility really mean?'.

That final question led me (via Google) to the World Wide Web Consortium (W3C) Web site, which seemed like a very promising resource for all questions related to accessibility. After all, they did write the book on this, didn't they?

After spending an entire morning jumping from link to link on that site, it became really clear to me that I was going to need to gird my loins for serious battle. The W3C documentation bears clear traces of its 'committee' heritage, and is as complex and voluminous as it is dry and tasteless. It felt like trying to down a plateful of fiber ... you know deep down that fiber's good for you, but that doesn't mean its going to make an attractive meal.

To get a sense of scale, see To Hell with WCAG2 by Joe Clark. The core of the latest guidelines by the W3C's Web Accessibility Initiative's (WAI) Web Content Accessibility Guidelines Working Group (WCAG) runs into a cool total of over 450 US letter-sized pages. This is further complicated by the fact that the documentation is split into multiple redundant parts - no one part of which can be read by itself, but require that a reader continually jump from one to the next and back.

To the sheer size of these "guidelines", you have to add what can only be euphemestically termed 'challenging language' in the documents. With over 20 years in the field of software engineering, and multiple degrees in computing, I don't consider myself a lightweight when it comes to reading technical literature. However, I must admit to feeling overwhelmed with the content in these tomes. The language feels stilted, and the definitions and terms used are confusing. In fact, the best parts in the document occur when they produce code snippets. When Javascript code actually feels easier than the text, you know that the document is more work than most.

So where should I start? Instead of focusing on all that's wrong with this specification (check out Joe's aforementioned opinions for yourself - there's enough ranting there to rival the WCAG 2 guidelines), I'm going to focus on my personal journey through this, erm, mess.

Web Content Accessibility Guidelines (WCAG)

WCAG Versions

According to the Web Accessibility Initiative WGAG 1.0 was approved in May 1999. While it informed accessibility-centric development for the past few years, it is quickly being superseded by fresh guidelines that are currently in the works - the WCAG 2.0 - which is anticipated to be completed in 2008.

Even though WCAG 1.0 is still the reigning king, for all practical purposes, I chose to focus on WCAG 2 - its not only more comprehensive, but also has more testing guidelines and examples. As with any "in progress" document, you have to read with the understanding that things could change before you complete reading the document. Note my self control at avoiding taking a dig at the size of the document yet again.

WCAG 2.0

The core of the WCAG 2 is found in these documents:

  1. Understanding WCAG 2:
    This can be considered a page authors' guide for the rationale behind the WCAG 2. If you are going to read one document from the WAI, this would be it. In fact, I would go so far as to call for the abolition of the other documents. They served no purpose other than make me think that they had valuable information, and led me down a merry wild goose chase of repeated and regurgitated information.
  2. Techniques and Failures for WCAG 2.0:
    If the former was the page author's guide, then this is the WCAG 2's developer's manual. It is chockful of HTML, CSS, and Javascript tips and tricks. As always, the WCAG chooses to obfuscate this excellent material by providing a listing of "Failures" which is most often the negative equivalent of the "Guidelines". So, you end up with a "Thou Shalt" section and another for the "Thou Absolutely Shalt Not". In addition, the "Thou shalts" are largely redundant with the tips and tricks sections. So, you end up reading thrice as much for a third of the benefit. Were the WCAG paid by the word?
  3. How People with Disabilities Use the Web:
    While not directly related to the WCAG 2.0, this document provides a wonderful introduction to the world view of users with various impairments and how you might ease their interactions with your Web site. As a result, it is a must read even if you care little about the WCAG 2.

With the admirable goal of doubling the text that any developer has to go through, the WAI kindly provides us with two additional redundant documents:

  1. Web Content Accessibility Guidelines:
    This document purports to be the main source of the WCAG 2. In fact, its table of contents reads like an accessibility checklist that you could use during development. However, it turns out to be just as useful as a skilled project manager - it simply delegates all the heavy lifting to its subordinates, primarily Understanding WCAG 2.
  2. WCAG 2.0 Quick Reference:
    This serves as the official checklist - and simply provides another orthogonal view of the WCAG 2.

Disabilities affecting Web accessibility

Disabilities are defined as limitations of sensory (visual, auditory, speech), physical, cognitive, or neurological functioning which can affect access to the Web. These not only include permanent disabilities (e.g., blindness), but also those acquired limitations associated with injuries, aging, or to side effects of medication (e.g., hand tremors).

In addition, disabilities can occur in combinations, as in the deaf-blind, and these limitations may occur at different levels of severity.

The problem at the heart of Web accessbility lies in (a) providing an alternative to the traditional monitor, keyboard, and pointing mechanisms of using a computing device, and (b) ensuring that the content itself is clear (readable) and does not cause harm (cause seizures, etc.) to users with all levels of abilities.

Assistive Technologies (ATs)

Depending on one's disabilities and their severities, a user may choose to use one or more technologies to assist them in accessing the computing device, and by extension your Web site. These technologies provide alternatives to either input or output peripherals connected to a computer.

  1. Alternatives to output devices:
    1. Screen Readers
      This is software that converts text on the monitor to digitized speech or to refreshable braille (which uses a mechanical display where pins can be raised or lowered to converts rendered text into braille characters.)
      Older versions rely on the rendered text, whereas newer versions can work directly with the DOM tree, so they can more closely replicate the document's structure. Examples include BrowseAloud, Job Access with Speech, and HomePage Reader.
    2. Screen Magnifiers
      This is software that magnifies a portion of the screen.
    3. Scanning software:
      Announces selection choices as you move through a list of links or menu items, and allows you to pick your choice by hitting a switch when it is selected.
    4. Text browsers
      In low bandwidth situations, provides a valid input to a screen reader.
    5. Visual notification
      Provides a visual alert for conditions that might normally be communicated by sound (e.g. a warning beep).
  2. Alternatives to input devices:
    1. Alternative keyboards or switches:
      This includes custom keyboards - i.e., those with extra small or extra large key spacing, with keyguards that only allow one key to be pressed at a time, on screen virtual keyboards, eye gaze keyboards, and sip and puff switches.
    2. Speech recognition software and Voice Browsers
      This is software that replaces a keyboard with speech recognition.

In addition, users who are unable to use a pointing device, may use the keyboard to Tab through the widgets on a page.


Limitations can be broadly organized into the following categories, with users potentially experiencing combinations of these limitations at varying severity levels.

  1. Visual limitations :
    1. Blindness :
      This relates to a substantial uncorrectable loss of vision in both eyes.
      Assistive Technologies: Screen readers, text/voice browsers, tabbing.
      Web Page Offenders: images without alt text; complex images or video that are not adequately described in plain text; tables that do not make sense when linearized by a screen reader; forms that cannot be tabbed through in a logical sequence, or whose fields are poorly labelled.
    2. Low vision (partially sighted) :
      This includes users with blurred or clouded vision, tunnel vision (only the middle of the visual field is visible); and central field loss (the opposite of tunnel vision). Assistive Technologies: Screen magnifiers.
      Web Page Offenders: Use of absolute font sizes or text presented as images, so that the user agent is unable to magnify the text; pages with poor contrast; etc.
    3. Color blindness :
      This is one of the most common visual disabilities for men. Shows up as a lack of sensitivity to some/all colors. E.g., difficulty in distinguishing between red and green, or yellow and blue. Assistive Technologies: Allow user style sheets to override author styles.
      Web Page Offenders: Color used to impart semantic meaning to text; inadequate contrast between text and its background.
  2. Hearing limitations :
    1. Deafness :
      Substantial uncorrectable impairment of hearing in both ears.
      Web Page Offenders: Lack of captions or transcripts for audio; requirements for voice input; inability to change the volume of the main content in relation to the background audio.
    2. Hard of hearing :
      Mild to moderate hearing loss. Web Page Offenders: As for deafness.
  3. Physical limitations :
    1. Motor disabilities :
      Weakness, limitations of muscular control (involuntary movements, lack of coordination, paralysis), limitations of sensation, joint problems, or missing limbs. Assistive Technologies: keyboard with a key layout that matches their range of hand motion; pointing device such as a specialized mouse or a head-mouse; eye gaze system; head pointer; mouth stick; voice recognition software; etc.
      Web Page Offenders: time limits for completing a form; lack of keyboard alternatives for mouse input; no logical tab order for forms.
    2. Speech disabilities :
      Difficulty producing speech recognizable by voice recognition software. Assistive Technologies: Alternative input mode such as text entered via a keyboard.
  4. Cognitive and Neurological limitations :
    1. Visual and Auditory Perception :
      Difficulty in processing language or numbers (dyslexia or dyscalculia). Dyslexia makes it difficult to recognize written or printed words and to associate them with the correct sounds, i.e., to decode the text. Decoding must be automatic in order for people to read fluently. Assistive Technologies: Screen reader with synthesized speech.
      Web Page Offenders: Lack of text that can be converted to audio.
    2. Attention deficit disorder :
      Difficulty focusing on information. Assistive Technologies:Turn off animations.
      Web Page Offenders:Distracting content that cannot be turned off.
    3. Intellectual/learning/development disabilities :
      Tend to learn slowly, and to have difficulty understanding complex concepts (e.g., Down's syndrome).
      Web Page Offenders:Use of complex language; lack of graphics to enhance understanding; lack of consistent organization.
    4. Memory impairment :
      Web Page Offenders:Lack of consistent navigational structure or breadcrumbs.
    5. Mental health disabilities :
      Difficulty focusing on information; blurred vision or hand tremors due to medication.
      Web Page Offenders: Distracting elements that cannot be turned off; content that doesn't lend itself to being enlarged by the user agent.
    6. Seizure disorders :
      Epilepsy (incl. photo-sensitive epilepsy) is triggered by visual flickering or audio signals at a certain frequency.
      Web Page Offenders:Use of animations, blinking text, or certain audio frequencies.

WCAG 2.0's Accessibility Rules

The WCAG 2.0 categorizes its accessibility rules in terms of general principles, guidelines and success criteria.

For the most part, the principles describe the "mom and apple pie" values and as a consequence seem to be more useful to the politician than the typical grunt developing a site. Guidelines serve as a functional "section-based" grouping of the actual rules, and I suspect will be more useful (say as a memory aid) once I have gained a level of expertise with the individual rules themselves.

The meat and potatoes of the WCAG 2 are the actual success criteria. Each criterion indicates in very specific detail the "Web page offenders" it is targeting, and what needs to be done in order to achieve its goals, along with HTML snippets, Javascript code, and CSS rules that might be helpful to a developer.

Each criterion has an associated conformance level, either "A", "AA", or "AAA". These levels map relatively loosely to must-have, nice-to-have, and pie-in-the-sky. A worthwhile goal therefore would be to implement all of the level "A" and "AA" criteria, and to optionally implement as many of the "AAA" criteria as your time and budget permit. At least, that's the strategy we're advocating for our project.

In the next few sections, I'm going to spell out the individual success criteria and their suggested fulfillment techniques. My aim is to distill the rules down to their essence - sort of a Cliff notes version of the WCAG 2. A danger with this is that I might misrepresent some of the facts related to these criteria - esp. as I'm operating without a technical reviewer here. As a result, I cannot overstress the importance of reading through the WCAG by yourself - so caveat emptor.

Please email me if I've got anything wrong, after all, I'm learning as I go. And, yes, please insert any legalese here to protect me from any reliance on the information contained herein.

Guideline 1.1: Provide text alternatives for any non-text content so that it can be changed into other forms people need such as large print, braille, speech, symbols, or simpler language.

Success Criterion 1.1.1: Non-text content: All non text content has a text alternative that presents equivalent information, except for the situations listed below. (Level A)

Plain text has the advantage that it can be rendered in different modalities (visually, audibly, or tactilely) depending on what best meets the needs of the user. It can also be enlarged, or spoken in a more understandable voice (i.e. with the right accents, etc.) This has the beneficial effect that plain text is the most accessible form of content on the Web.

As a result, any non-text content (images, audio, video, even images of text) should be translatable into its equivalent representation in plain text. I.e., replacing the image by this plain text should lose no information.

Techniques for meeting criterion 1.1.1
  1. When the non-text content can be described by an equivalent short description:
    Provide the short text in the element's alt attribute. This applies to <img> tags, <input> tags of type <image>, and <area> elements of <map> tags.
    <input type="image" name="submit" src="button.gif" alt="Submit" />
    <img src="news.gif" alt="Free newsletter. Get free recipes, news, and more." />
  2. When a short alternative is not sufficient, either (a) indicate in the alt text that a description follows the content, and provide a longer description after the non-text content (such as the table underlying a pie chart graphic), or (b) use either the longdesc attribute or an anchor link that takes the user to plain text content.

The criterion exempts certain forms of non-text content - viz.,

  1. Completely Automated Turing test to tell Computers and Humans Apart (CAPTCHA)
    Provide alt text that indicates the purpose of this test, and provide an alternative that uses a different modality (e.g., either an audio equivalent of the image, or a form field that asks "What is 2+7:"
  2. The non text content represents a complex applet
    Use alt text to at least describe the purpose of the control, (e.g., Control for aiming and zooming a remote video camera.)
  3. The non text content represents a form field
    Explicitly assign a label to the field.
    For the input (text, checkbox, radio, file, password), select, and textarea tags, use an explicit <label> element.
    <label for="firstname">First Name: </label> <input type="text" name="firstname" id="fname" />
    <input type="checkbox" name="flavor" id="chocolate" value="c" /> <label for="chocolate">Chocolate</label>
    When visual design precludes the use of a label, use the input tag's title attribute instead.
    For input buttons of type="submit" or "reset", use the value attribute.
    For input buttons of type="image", use the alt attribute.
    For input elements of type="button", use the element body itself.
  4. For multimedia (e.g., a picture of the Mona Lisa), live audio/video feeds, or a question used to test a particular sense (Can you hear this sound?):
    Describe the content to the user even though they cannot access it. E.g., "Mona Lisa, by Da Vinci", or "Live video of the I-494 and Hwy 61 interchange".
  5. Decorative content (e.g., border patterns, or background images)
    Set alt to "" and omit the title attribute. This effectively asks the assistive technology to ignore such content.

When non text content changes, ensure that the description does as well. A script is used to update the image on a page, but the alt text is not updated.

Guideline 1.2: Provide synchronized alternatives for multimedia

[Omitted for now ... to be filled in later. Please see the Understanding WCAG 2.0 document for details.]

Guideline 1.3: Create content that can be presented in different ways (e.g., spoken aloud, simpler layout, etc.) without losing information or structure

1.3.1 Info and Relationships: Information and relationships must be programmatically determinable or available in text. (Level A)

Visual cues are often used to perceive structure and semantic information in a document. For e.g., structure in a document is usually perceived using cues, such as headings being in a bolder font separated by blank lines, and list items being preceded by bullets and being indented. Similarly semantic information, such as words that need to emphasized, are communicated by italicizing them.

  1. Structural relationships should be encoded programmatically using the appropriate markup elements, e.g., H1-H6 to indicate headings and subheadings, or table rows and cells, and dl, ol and ul for list items.
    Similarly, semantic information such as emphasis should be conveyed by markup like <strong> rather than using CSS to style plain text to bold. Other semantic elements include <em>, <abbr>, <strong>, <cite>, <quote>, <sub>, <sup>, <blockquote>, and <q>. As a result, even if the presentation modality changes, the information and structure are preserved since the markup elements convey information to the user agent.
    E.g., a screen reader can read content marked up by the <em> element using a different voice pitch, and it allows the use of user style sheets to change the presentation Note that assistive technologies will not be able to discover this information if plain text is simply styled visually to resemble headings, list items, or using a fieldset to apply a border, etc. Using markup makes this information perceivable to all users, across different modalities.
  2. A set of radio buttons or checkboxes is usually related when they share the same name attribute. Using a fieldset to enclose the set as well as a legend, will cause readers to speak the description as well as the available responses.
  3. If any semantic information is being conveyed by a change in visual appearance of the text (e.g., by a change in font face, size, or style) or by a change in color, then that information must also be made available elsewhere in the content via plain text. E.g., the semantic information that a field is mandatory could be conveyed by making the field bold and red. This information should also be conveyed via instructional text that states all required fields are displayed in red and are emphasized followed by an example.
  4. When you add new content to a page, make sure that the screen reader is aware of that content by (a) setting focus to the new element, or (b) by adding it below the current location so that it will be encountered as the user continues to traverse the page. Avoid adding new content using document.write(), or object.innerHTML. The former does not work with XHTML and a MIME type of application/xhtml+xml, and the latter is not part of the DOM spec. Instead use the DOM functions createElement(), createTextNode(),append/remove/replaceChild(), and insertBefore(). When adding focusable elements in the middle of a document, do not add tabindex attributes to explicitly set the tab order. Let the default tab order be used instead.
  5. For tables, the following should be considered:

1.3.2 Meaningful Sequence: (Level A)

If content has items that appear in some meaningful sequence, then that sequence must be maintained even when the content is presented in a different modality. A sequence is meaningful if the order of content in the sequence cannot be changed without affecting its meaning - e.g., ordered lists are meaningful sequences, but unordered lists are not.

The sequence of content may also be affected when tables are linearized by screen readers. Tables present data in 2 visual dimensions, but readers present this in linear order of the content in the source, beginning with the first cell in the first row, and ending with the last cell in the last row; reading the contents of each row, before moving on to the next row; and speaking out the complete content of each cell in each row, including that of any table nested within that cell. Because of this linearization any meaningful sequence conveyed through visual presentation may not be perceivable when the content is spoken.

1.3.3 Size, Shape, Location: Instructions provided for understanding and using content do not rely on shape, size, visual location, or orientation of components. (Level A)

UI components should not be referenced by color, shape ("round button"), size, or location ("button to the right"), i.e., do not rely on information not readily available from the structure of the content. Users may not be able to perceive these properties due to the nature of the assistive technology used. I.e., they may perceive only a small portion of the screen at one time, and location can vary due to variations in the size of the font, window, or screen.

Any items referenced by color, shape, size, or location must also be referenced in ways that do not depend on visual perception (e.g., by their function or label):

Guideline 1.4 Make it easier for people with disabilities to see and hear content including separating foreground from background

1.4.1 Use of Color: Any information that is conveyed by color differences (i.e. that depends on the user's ability to differentiate between colors) is simultaneously visually evident without the color differences. (Level A)

Information conveyed by color must also be explicity conveyed in plain text:
All required fields are displayed in red and marked with an asterisk * followed by an example; or each colored icon has alt-text with a short description

If color is used within an image, such as a pie chart, to convey information , then use patterns to convey the same information. E.g., solid and patterns are used to represent different color bars in a graph; or in addition to different colored icons, use different icons to represent different routes.

Also, ensure that the text alternative for the image conveys that same information.

1.4.2 Audio Turnoff: If any audio plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume which can be set independently of the system volume. (Level A)

When using a screen reader, it is difficult to hear the words if there is other audio playing at the same time. This is especially a problem when the speech output is controlled via the same volume control as this sound. So, provide a way to turn off background sound, or stop it automatically after 3 seconds or less.

1.4.3 Contrast (Minimum): Text (and images of text) have a contrast ratio of at least 5:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 3:1. (Level AA)

There should be enough contrast between the text and its background. Contrast is calculated without considering color, so that people with a color vision deficit will also have adequate contrast. See the WCAG 2.0 guidelines for links to utilities that help measure contrast.

The simplest is not to specify the colors of the text as well as the background. But if you must, ensure that you specify both with sufficient contrast. <body color="white" bgcolor="black">
<style type="text/css"> body {color:white; background-color:black;}</style>

1.4.4 Resize text: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality. (Level AA)

You should provide direct support for resizing text or changing layout - e.g., via server side script that can be used to assign different style sheets; or at least not prevent the browser from scaling text.

As scaling increases beyond 200% (twice width and height), adaptive layouts may introduce usability problems - words may be too wide to fit into the space available to them, causing them to be truncated; text may overlap with other content; or only one word may fit on each line, making it harder to read the sentence when it is displayed as a vertical column.

To ensure browser support for scaling text, do not specify font sizes in absolute units. Instead, specify text font sizes using (a) proportions, strong {font-size: 120%} ; (b) named font sizes that express the relative size desired, strong {font-size: larger}; or (c) em units, strong {font-size: 1.6em}

Use liquid layouts which adapt to the available horizontal space by reflowing as necessary. Position the layout regions as a row of adjacent floating boxes. Define the size of layout regions using units that will cause it to scale relative to the text. E.g., using the float, clear, etc. CSS attributes.

1.4.5 Contrast (Enhanced): Text (and images of text) have a contrast ratio of at least 7:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 5:1. (Level AAA)

Same as for 1.4.3.

1.4.6 Low or No Background Audio: Audio content that contains speech in the foreground does not contain background sounds, background sounds can be turned off, or background sounds are at least 20 decibels lower than the foreground speech content, with the exception of occasional sound effects. (Level AAA)

[Omitted for now ... to be filled in later. Please see the Understanding WCAG 2.0 document for details.]

1.4.7 Resize and Wrap: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality and in a way that does not require the user to scroll horizontally. (Level AAA)

Provide options to use a variety of layouts with different font sizes. Use single column layouts. Use relative units and liquid layouts.

Guideline 2.1 Make all functionality available from a keyboard

2.1.1 Keyboard: All functionality is operable via a keyboard without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)

This translates from elven-speak to: All functionality is available using a keyboard without requiring finger gymnastics, except in the cases where the path taken is just as significant as the destination (as in free hand drawing; but not for drag-and-drop, where only the destination is material).

Keyboard access is required for the blind (devices like mice need hand-eye coordination), those with low vision (trouble with tracking a pointer on screen), and those with hand tremors.

2.1.2 All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level AAA)

Removes the exception for path-dependent inputs.

Guideline 2.2 Provide users with disabilities enough time to read and use content

Many users need more time to complete tasks like filling out forms than the majority of users. They take longer to physically respond, to read things, to find things, or they may be using assistive technologies that require more time. This guideline eliminates or relaxes time constraints.

2.2.1 Timing: For each time limit that is set by the content , at least one of the following is true: (Level A)

If there is no hard time limit required to be imposed:
Provide a checkbox to allow users to request a longer session time limit (up to 10x the limit), or no limit (as long as there is no privacy or security issue). I.e., with the text: Allow as much time as I need to complete this form. I understand that I must close the Web browser if I choose to stop before completing the last part of the form. OR Allow additional 15 minutes to complete each part of this form.
A script notifies users of an imminent (20 seconds or more) time limit, and allows the user to extend this time limit some number of times with a simple action. If the user requests additional time, the timer is reset.


  <script type="text/javascript">


    function timeControl() { setTimeout('userCheck()', 280000); } // timer set to 4m 40s

    function userCheck() {

      var id=setTimeout('pageReload()', 20000); // set page refresh for 20 seconds

      if (confirm("This page refreshes in 20s. Would you like more time?")) {





    function pageReload() { window.location.reload(true); }





This script may optionally prompt the user to enter a larger default time limit between refreshes.

Using a client side redirect to refresh a page after a time delay often makes the page inaccessible to screen readers since blind users will not have enough time to make their readers read the page before it refreshes unexpectedly and causes the reader to begin reading at the top. It is acceptable to use this with time-out set to 0, since the redirect is instant and will not be perceived as a change in context.

  <head><meta http-equiv="refresh" content="5;url=" /></head>

  <body><p>If your browser supports the refresh meta tag you will be transported to <a href="...">here</a> in 5 seconds.   Else, select the link manually.</p></body>


  response.setContentType("text/html"); response.setHeader("Refresh", "10;url=targetPage.html");


However, it is still preferable to let users choose when they want the latest information, or to use server-side 302 redirect HTTP response and a Location header with the new URL to do this.

2.2.2 Blinking: Content does not blink for more than three seconds, or a method is available to stop all blinking content in the Web page. (Level AA)

Avoid the <blink> element, or the CSS text-decoration property setting of blink, or blinking in an applet or plugin, since users can't control the blink.

Use a script to start and stop the blinking effect:

<div id="blink1">New item!</div>

<script type="text/javascript">


  function show() {

   if (document.getElementById) document.getElementById("blink1").style.visibility="visible";


function hide() {

  if (document.getElementById) document.getElementById("blink1").style.visibility="hidden";


for (var i=900; i < 2700; i=i+900) { //toggle on and off every 450 ms to blink. Stop after 2.7s.

  setTimeout("hide()", i);

  setTimeout("show()", i+450);





2.2.3 Pausing: Moving, blinking, scrolling, or auto-updating information can be paused by the user unless it is part of an activity where timing or movement is essential. Moving content that is pure decoration can be stopped by the user. (Level AA)

Provide keyboard shortcuts or input controls to allow users to stop content from advancing or updating at a rate beyond the user's ability to read or understand the content. E.g., animations, stock tickers, etc.

2.2.4 Timing: Timing is not an essential part of the event or activity presented by the content, except for non-interactive multimedia and real-time events. (Level AAA)

This differs from criterion 2.2.1 in limiting exceptions to real-time events. So, provide all the time needed to complete an activity. i.e. don't require any timed interaction.

2.2.5 Interruptions: Interruptions, such as updated content, can be postponed or suppressed by the user, except interruptions involving an emergency. (Level AAA)

For pages that automatically update content, provide users with a preference or user field to turn off or postpone updates except in emergencies (civil alerts, or other dangers to health or property, loss of data, loss of connection etc.) This allows users to keep their focus on the content they are currently reading without distraction.

E.g., if the updates are delivered by Javascript alerts, then provide buttons to turn off the alerts:

<body><p>Press button to enable display of famous quotes.</p>

<button id="enableBtn" type="button" onclick="modifyAlerts(true);">Turn Alerts on</button>

<button id="disableBtn" type="button" onclick="modifyAlerts(false);">Turn Alerts off</button>

<script ...>

var bDoAlerts = false;

function modifyAlerts(isEnabled) { bDoAlerts  = isEnabled; }

function doAlert(aMsg) { if (bDoAlerts) alert(aMsg); }

var counter = -1;

var quotes = new Array {"quote 1", "quote 2", "quote 3"};

function showQuotes() {

  if (++counter >= quotes.length) counter = 0;


 setTimeout("showQuotes();", 10000);





2.2.6 Re-authenticating: When an authenticated session expires, the user can continue the activity without loss of data after re-authenticating. (Level AAA)

For security reasons, sites implement an authentication time limit after a certain period of inactivity. E.g., if a shopping session times out while entering payment information, users must have the ability to reauthenticate and continue with the transaction without the loss of any data already entered. I.e., the server should restore the state prior to the timeout, as if there had never been a timeout.

If the session state were not restored, the user would have to start all over again. For these users, it is likely that they will timeout again. I.e., the user may never be able to complete the form.

The server needs to cache this state only long enough to ensure success after reauthentication in a single user session - such as one day.

Guideline 2.3 Do not create content that is known to cause seizures

Users with seizure disorders can have seizures triggered by content that flashes at certain frequencies for more than a few flashes. People are even more sensitive to red flashing. Unfortunately, warnings do not work well because they are often missed - esp. by children who may not be able to read them.

2.3.1 Three Flashes or Below Threshold: Content does not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. (Level A)

Most content does not flash at all, and even content that blinks does not blink this fast except on rare occasions. To avoid having to carry out the more complex testing required by this criterion, simply ensure that content only flashes 1, 2, or 3 times in any 1-second period. In particular, avoid content that contains a video clip or animated image of a series of strobe flashes, or closeups of rapid fire explosions.

2.3.2 Three Flashes: Content does not contain anything that flashes more than three times in any one second period. (Level AAA)

Stricter since it eliminates all flashing components that flash more than 3 times per second. Magnification at any level would not yield content that would fail the general flash or red flash thresholds. This is actually easier to test, and so should be used to meet the level A criterion.

Guideline 2.4 Provide ways to help users with disabilities navigate, find content and determine where they are

2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)

Sighted users automatically ignore repeated material, either by focusing on the center of the screen (where main content usually appears) or by quickly selecting a link that thakes them to the desired content without having to encountering every link or form control that comes before the item they want. This criterion allows users who navigate linearly to get more direct access to the primary content of the page. E.g., to avoid having to hear all heading graphics and dozens of navigation links read (the repeated content) before the main content is spoken, or to make dozens of keystrokes before reaching a link in the main content area.

  1. Create a link to skip blocks of repeated material:
    The first interactive item on the page must be a link to the beginning of the main content. E.g., Skip to lead story link on a newspaper page, where the lead story is in the middle of the page, surrounded by a search function, a corporate banner, navigational controls, sidebars, minor stories, contact information, etc. A visible link is preferred since it is available to users using techniques that generate keyboard strokes slowly, screen magnification software, those using voice recognition software, etc.
  2. The first link in a block of material should move focus past the block (on to the next menu or section).
  3. For pages with many independent sections, such as portals, provide a list of links at the top of the page to each area of the content.
  4. Use H1-H6 to mark each section in a document. Most assistive technologies provide a means to navigate by heading elements by allowing users to jump from one heading to the next.
  5. Group links into logical units using ol or ul:
      <a name="categories" id="categories"></a><h2>Product Categories</h2>
      <ul class = "navigation">
        <li><p><a href="kitchen.html">Kitchen</a></p></li>
        <li><p>< a href="storage.html">Storage</a></p></li>
      Using CSS to remove list bullets and to flow the list items horizontally:
      ul.navigation { list-style:none; padding:0;}
      ul.navigation li {display: inline;}
      To remove list bullets and display items in a floating block:
      ul.navigation { list-style:none; padding:0;}
      ul.navigation li {display: block; float:left;}
  6. Group repeated material into frames

2.4.2 Page Titled: Web pages have descriptive titles. (Level A)

A title should identify the subject of the page, make sense when read out of context (e.g., by a reader), be short, and unique within the site. When titles appear in site maps, users can more quickly identify the content they need without having to read and interpret page content. <head><title>xxxx</title></head>

2.4.3 Focus Order: If a Web page can be navigated sequentially, focusable components receive focus in an order that follows information and relationships conveyed through presentation. (Level A)

A user using a screen magnifier sees only a small portion of the page. So, if the tab order skips between different form sections, then the user may believe that a section has been completed, and try to submit the form, and be surprised at the error that results. Often placing the interactive elements (forms and controls) in an order that follows relationships is sufficient. It is easy to introduce usability bugs when setting the tab order explicitly. Use the tabindex attribute of each interactive element to explicitly set the order. Elements are given focus in increasing order of the value of their tabindex. After all elements with a tabindex higher than 0 have received focus, the rest of the interactive elements are given focus in the order that they appear on the page.

2.4.4 Link Purpose (Context): The purpose of each link can be determined from the link text and its programmatically determined link context. (Level A). This requirement may be eliminated.

To properly define the purpose of a link ensure that the link text is meaningful; use title to provide additional information; and provide hidden supplemental text. This supplemental text is not hidden by the traditional means of visibility:hidden or display:none, since these often hide text even from assistive technologies.

  a span {height: 1px; width: 1px; position: absolute; overflow: hidden; top:-10px; }


  <a href="#"><span>Washington stimulates economic growth</span>Full Story</a></p>


  <a href="war.html"><span>War and Peace</span>HTML</a>

  <a href="war.pdf"><span>War and Peace</span>PDF</a>


The context for understanding the purpose of a link should be located in the same sentence, paragraph, list item, or table cell as the link itself. If the user must leave the link to search for the context, the context is not programmatically determinable.

2.4.5 Multiple Ways: More than one way is available to locate content within a set of Web pages where content is not the result of, or a step in, a process. (Level AA)

Users with visual impairments may find it easier to navigate using a search, rather than scrolling through a large nav bar using a reader. Cognitive-disabled may find it easier to explore the site via a site map rather than traversing individual pages or using a hierarchical scheme. So provide alternative options to navigate your site.

A document could have a table of contents that has links to sections and subsections of the same document, or it could be used across pages when a "logical" document is divided into multiple pages.

Some browsers can provide an optional nav bar using information supplied in the link element - whose rel attribute can provide information on a page's position within a set of Web pages, which can be set to Contents, Start, Next, Prev, Index, or Contents.

2.4.6 Labels Descriptive: Headings and labels are descriptive. (Level AA)

Putting the most important information at the beginning of each heading lets users skim the headings to locate the specific content they need. Esp. useful when the assistive tech allows navigation from heading to heading. Similarly, associating labels with interactive controls allows assistive technologies to recognize the label and present it to the user.

2.4.7 Location: Information about the user's location within a set of Web pages is available. (Level AAA)

A bread crumb trail could show the locations in the path that the user took to reach this page as links, or the location of the current Web page within the site's organization or a site map could show the site's layout.

You could also use <link rel...> or include relevant information in the title of the page to identify the relationship between the current Web page and the other pages in the same collection.

2.4.8 Link Purpose (Link Text): The purpose of each link can be identified from the link text. (Level AAA)

When the purpose of a link can be identified from its link text, links can be understood even when they are out of context, as in a screen reader that lists all the links on a page. This helps people ignore links that they are not interested in.

2.4.9 Section Headings: Where content is organized into sections, the sections are indicated with headings. (Level AAA)

When a page is organized into sections, provide headings for each section to indicate the organization of the content, and to provide mental handles that aid in comprehending the content. Visual presentation elements (e.g., horizontal rules and boxes) may complement headings, but are not sufficient to identify sections. Helps visually impaired to navigate the document.

Guideline 3.1 Make text content readable and understandable

3.1.1 Language of Page: The default human language of each Web page within the content can be programmatically determined. (Level A)

The default language of the document must be identified using the html attribute's xml:lang (for XHTML 1.1) and lang (HTML 4.01) attributes. XHTML 1.0 understands both.

  <html xmlns="" lang="fr" xml:lang="fr">


If the language of the page is identified, readers can load the correct pronunciation rules (else the French word voiture would be pronounced voyture by a reader that uses English as its default language), visual browsers can display the correct characters, braille translation software can work correctly, and media players can show the right captions. As a result, users will be better able to understand the content.

3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically determined. (Level AA)

HTML 4.01 supports the lang attribute on elements; XHTML served as text/html uses the lang and xml:lang attributes; XHMTL served as application/xhtml+xml uses the xml:lang attribute on elements. <span lang="fr">je ne sais quoi</span>

3.1.3 Unusual Words: A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms (e.g., spilling the beans, or kicking the bucket) and technical jargon. (Level AAA)

Certain disabilities also make it difficult to understand figurative idiomatic language. Also, words may be used in an unusual way, i.e., where a particular meaning of the word must be used in order to understand the context.

This criterion requires that definitions be provided for idioms, phrases, abbreviations, as well as for any word used in with a special meaning in mind.

The definition may be provided either inline in the text, just before or just after the word is used. E.g., It may be necessary to update the driver for your printer (the driver is software that contains specific instructions for your printer.)
Or, a link may be provided to the definition in an alphabetized glossary placed either at the end of a Web page, or in a separate page.
Some browsers support linking to a glossary via a link tag in the head element of the document.
<link rel="glossary" href="#glossary">

Definitions should be specified using the dl, dt, and dd structural elements to ensure that relationships between terms and their definitions are preserved irrespective of presentation mode (modality) used.

3.1.4 Abbreviations: A mechanism for finding the expanded form or meaning of abbreviations is available. (Level AAA)

Abbreviations can confuse screen readers in multiple ways:

Include the abbreviation immediately following the expanded form the first time it occurs on the page. The United Nations High Commissioner for Human Rights (UNHCR) was established in 1950.

Alternatively, use either the abbr or acronym elements to provide an expansion:

Welcome to the <abbr title="World Wide Web">WWW</abbr>! OR
The use of <acronym title="Keep it simple stupid">KISS</acronym> became popular in ...

Provide expansions using the following rules:

3.1.5 Reading Level: When text requires reading ability more advanced than the lower secondary education level, supplemental content or an alternate version is available that does not require reading ability more advanced than the lower secondary education level, i.e., more than 9 years of school. (Level AAA)

There are people with disabilities (incl. reading disabilities like dyslexia) even among highly educated users with specialized knowledge of the subject matter. So when the original content is complex, provide a short summary subsection that identifies the most important ideas in the content and uses shorter and more common words, and shorter sentences. Alternatively, provide visual illustrations to supplement the text (e.g., charts, graphs, animations, diagrams); or provide a spoken version of the text.

3.1.6 Pronunciation: A mechanism is available for identifying specific pronunciation of words where meaning is ambiguous without knowing the pronunciation. (Level AAA)

When the screen reader reads a word using the wrong pronunciation, it can be even more difficult to understand than when read visually. E.g., in English, heteronyms are words that are spelled the same but have different pronunciations and meanings, e.g., the words desert (abandon) and desert (arid region); or Kanji characters that have multiple pronunciations. When read incorrectly the content will not make sense to users. Provide pronunciation hints either as a link to a sound file, or using phonetic symbols to help the user.

Guideline 3.2 Make Web pages appear and operate in predictable ways

3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. (Level A)

An example of a change of context is the display of a new page or a new window, a change of field focus, or a form submission. Any change of context should occur only by the user taking some specific action that may be tied to a change in context. E.g., a change of context is expected when a user clicks a link or presses a submit button. However, a change of context would be unexpected if simply tabbing to a field (an action that is not normally associated with a change of context) causes a form to be automatically submitted, or a new window is opened. Users who experience an unexpected change of context may become disoriented. Ensure that adequate instructions are provided near any controls that result in a context change.

3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)

Changing the value of a form control is not typically associated with a change of context. If a change of context must be associated with changing a control's value, it is important to provide information about what will happen when the control is changed. For e.g.,

Alternatively, provide a mechanism that allows users to explicitly request changes of context - e.g., via a submit button that submits data entered in a form.

3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. (Level AA)

To make the placement of repeated content more predictable, present them in the same relative order each time they appear. Other components can be inserted between them, but their relative order is not changed. Also applies to navigational components (menu, breadcrumbs). E.g.,

3.2.4 Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently. (Level AA)

Users of screen readers rely on their familiarity with functionality that appears on different Web pages. If identical functions are called different names on different pages, the site will be more difficult to use. (e.g., don't mix "Search" and "Find" and "Locate"; or "Save Page" and "Save" to refer to the same functionality.) At least the label prefix must be identical (e.g. "Go to page 4", "Go to page 5"; and "Download Manual", "Download Driver").

If icons have the same functionality, then their text alternatives should be consistent as well (exception is where a check mark icon may have different semantics - approved, completed, included, etc.)

3.2.5 Change on Request: Changes of context are initiated only by user request. (Level AAA)

When a page is refreshed, the screen readers virtual cursor, which marks the user's current location on the page, is moved to the top of the page. An auto-refreshing page can therefore be very confusing. In particular, avoid automatically refreshing for full page content - unless there is an option to disable this behavior. E.g., avoid a slideshow that automatically advances to the next slide with no pause/stop button. Instead, provide a mechanism, e.g., a link, that allows the user to explicitly request a content update. <a href="news.jsp">Update this page </a>

In a client side redirect, a temporary page is displayed, which is then refreshed with the contents of the redirect URL. This involves a context change that is not initiated by the user. <head><meta http-equiv "refresh" content="0;URL=''" /> A server side redirect is preferred because it does not cause new content to be displayed before the server sends the content located at the new URL.

Avoid opening up windows that are not requested or expected by the user. Suddenly opening new windows can disorient or be missed completely by some users. If the target attribute is not permitted (HTML 4.01 or XHTML 1.0 Strict), new windows can be opened by script.

  <a href="help.html"  id="newwin">Show Help</a>



  function addHandlers() {

    var objAnchor = document.getElementById('newwin');

    if (objAnchor) { = + ' (opens in a new window)';

      objAnchor.onclick =function(event) { return launchWindow(this, event);}

      objAnchor.onkeypress = function (event){return launchWindow(this, event);}



  function launchWindow(objAnchor, objEvent) {

    var iKeyCode, bSuccess = false;

    if (objEvent && objEvent.type=='keypress') {

      if (objEvent.keyCode) iKeyCode = objEvent.keyCode;

      if (objEvent.which) iKeyCode = objEvent.which;

      if (iKeyCode != 13 && iKeyCode != 32) return true;


    bSuccess =;

    if (!bSuccess) return true; //if popup didn't open, do default of opening in same window

    return false; //stop processing any further - the popup was opened



When there are more than one select elements on a page, an onchange on one could update the options in another on the page without a change of context. The modified (dependent) select item occurs after the triggering select element in the reading order for the page. This ensures that assistive technology will pick up the change and that users will encounter the new data when the modified element receives focus.



    <noscript> This page needs Javascript to be enabled </noscript>

    <select id="continent" onchange="countryChange(this); ">

      <option value="empty">Select a Continent</option> ... "NA"North America, etc


    <select id="country">

      <option value="0">Select a country</option>



  In the Head Script:

  <script type="text/javascript">


       var countryLists = new Array(4);

       countryList["empty"] = ["Select a Country"];

       countryList["North America"] = ["Canada", "United States", "Mexico"];

       function countryChange(selObj) {

        var idx = selObj.selectedIndex;

        var which = selObj.options[idx].value;

        cList = countryLists[which];

        var cSelect = document.getElementById("country");

        var len = cSelect.options.length;

        while (cSelect.options.length > 0) { cSelect.remove(0); }

        var newOption;

        for (var i=0; i < cList.length; i++) {

          newOption = document.createElement("option");


          newOption.text = cList[i];

          try { cSelect.add(newOption);} catch(e) {cSelect.appendChild(newOption);}






Guideline 3.3 Help users avoid and correct mistakes

People with some difficulties may find it more difficult to enter error free input, and to detect when they have made an error. Typical error indication methods may not be obvious to them because of a limited field of view, limited color perception, or use of assistive technology.

3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and described to the user in text. (Level A)

Error message should be specific. On an unsuccessful form submission, redisplaying the form and indicating the fields in error is insufficient for some users. E.g., screen readers will not know there was an error until they encounter one of the indicators. It is not sufficient to simply indicate that a field has an error by putting an asterisk on its label, or by turning the label red. A text description of the problem should be provided.

When a mandatory field has not been completed, notify the user using

When a user entered value fails validation,

The description of the validation error must describe the correct data entry for the field, provide examples of the correct data entry for the field, and show values of the correct data entry that are similar to the user's data entry, with instructions to the user as to how to enter one of these correct values should the user choose to do so.
<input type="text" name="date" id="date" onchange="if (isNaN(Date.parse(this.value))) alert("This control is not a valid date. Please reenter the value"); />

3.3.2 Error Suggestion: If an input error is detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)

If information provided by the user is required to be one of a limited set of values, then text description should indicate this fact. i.e., include the list of values possible, or suggest the allowed value that is most similar to the entered value. E.g., "Choose one of: January, February, March, April, May, June, July, August, September, October, November, December." And, "Do you mean 'December'?"

3.3.3 Error Prevention (Legal, Financial, Data): For forms that cause legal commitments or financial transactions to occur, that modify or delete user-controllable data in data storage systems, or that submit test responses, at least one of the following is true: (Level AA)

3.3.4 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level AA)

Provide simple instructions and cues that are visually connected to form controls without cluttering the page with unnecessary information. Too much information can be just as much hindrance as too little.
E.g., inform users about any restrictions on the format of data that users must enter.

<label for="date">Date (dd-mm-yyyy)</label><input type="text" name="date" id="date" />

3.3.5 Help: Context-sensitive help is available. (Level AAA)

Context sensitive help is only required to be provided when the label is not sufficient to describe all functionality. It should not be placed in the form itself, but be available to users when they request it - by linking to a separate help file.

3.3.6 Error Prevention (All): For forms that require the user to submit information, at least one of the following is true: (Level AAA)

This builds on 3.3.3 in that it applies to all submitted forms.

Guideline 4.1 Maximize compatibility with current and future user agents, including assistive technologies

The key takeaway was that every Web page should be validated against a formal specification. Issues to look out for were remembering to close all tags, to nest elements correctly, and to assign unique values for the id attribute within a document.


I set out with the goal of providing a synopsis of the WCAG 2 - and by now you know whether or not I've succeeded. Be that as it may, it is important to note that accessibility is here to stay, and that it is not incompatible with rich user interfaces. All that is required is what is termed 'graceful degradation', where your rich UI remains rich for those able to experience it as such, but still functions, albeit at a reduced level of richness, for those who cannot.

Valid XHTML 1.0 Strict