Jump to main contentmickwood.com - Website Hosting & Design for Christian Organisations
2 Corinthians 1:21,22 - Now it is God who makes both us and you stand firm in Christ. He anointed us, set his seal of ownership on us, and put his Spirit in our hearts as a deposit, guaranteeing what is to come.

What are the Web Content Accessibility Guidelines?


The World Wide Web Consortium (W3C) is an international industry consortium jointly hosted by the MIT Laboratory for Computer Science in the USA, the National Institute for Research in Computer Science and Control in France, and Keio University in Japan. There are approximately 450 member organizations of the Consortium.

The W3C provides a number of services including a collection of World Wide Web resources for developers and users, reference code examples to represent and promote standards and various prototype and sample applications to demonstrate the use of new technology.

The W3C are committed to the disabled and formed the Web Accessibility Initiative (WAI) to promote Web accessibility. The WAI is pursuing accessibility of the Web through five primary areas of work:

  1. addressing accessibility issues in the technology of the Web
  2. creating guidelines for browsers, authoring tools, and content creation
  3. developing evaluation and validation tools for accessibility
  4. conducting education and outreach
  5. tracking research and development.

There are two versions of the Web Content Accessibility Guidelines (WCAG). WCAG 1 contains 14 main guidelines with a total of 65 in all. WCAG 2, still in draft format, has reorganised and combined many of the WCAG 1 guidelines to create 21 new ones.

Each guideline has a one or more ‘checkpoints’ which developers should consider to ensure the accessibility of a Web page. Each checkpoint has a priority level based on its impact on Web accessibility.

The WCAG provides a number of examples and techniques to help Web developers to implement the guidelines. There is also a downloadable training course entitled the Curriculum for the Web Content Accessibility Guidelines 1.0. The course is a few years old and needs updating. Saying that, it does provide a good foundation to the topic.

WCAG Priority Levels

There are 3 WCAG priority levels. Compliance with the recommendations of each level ensures greater accessibility of Web pages.

Priority 1 - Web developers MUST satisfy these checkpoints or some groups of people will find it impossible to access information on their site. This is considered to be the absolute minimum level of compliance.

Priority 2 - Web developers should satisfy these checkpoints or some groups of people will find it difficult to access information on their site. This is considered to be the preferred level of compliance.

Priority 3 - If Web developers satisfy these checkpoints the majority of users will be able to access ALL of the information on their site. This is considered to be the optimum level of compliance.

WCAG Conformance

The WCAG guidelines have three levels of conformance.

  1. Conformance Level "A": all Priority 1 checkpoints are satisfied. This is known as 'WCAG A' compliant.
  2. Conformance Level "Double-A": all Priority 1 and 2 checkpoints are satisfied. This is known as 'WCAG AA' compliant.
  3. Conformance Level "Triple-A": all Priority 1, 2, and 3 checkpoints are satisfied. This is known as 'WCAG AAA' compliant.

There are 14 main WCAG guidelines as follows: -

1 - ‘Provide equivalent alternatives to auditory and visual content.’

The aim is to provide content that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content. Although some people cannot see images, movies, sounds, applets, etc. they may still use pages that include equivalent information to the visual or auditory content. The equivalent information must serve the same purpose.

For example, each image should also include alternative text via the ALT attribute. Suppose the alt text for a button says 'button'. This does not convey the purpose of the button. It is much better to put 'link to home page' or something along these lines.

This guideline emphasizes the importance of providing text equivalents of non-text content. The beauty of a text equivalent lies in the fact that it can be rendered in ways that are accessible to people with various disabilities using a variety of assistive technologies. Text can be easily output to speech synthesizers and Braille displays, and can be presented visually on computer displays and paper.

Synthesized speech is critical for individuals who are blind and for many people with the reading difficulties that often accompany cognitive disabilities, learning disabilities, and deafness.

Braille is essential for individuals who are both deaf and blind, as well as many individuals whose only sensory disability is blindness.

Text displayed visually benefits users who are deaf as well as the majority of Web users.

Non-text content such as video obviously benefits some users, especially non-readers or people who have difficulty reading. In video or other visual presentations, visual action such as body language or other visual cues may not be accompanied by enough audio information to convey the same information. Unless verbal descriptions of this visual information are provided, people who cannot see (or look at) the visual content will not be able to perceive it.

2 - ‘Don't rely on colour alone.’

It is vital to ensure that text and graphics are understandable when viewed without colour. If colour alone is used to convey information, people who cannot differentiate between certain colours and users with devices that have non-colour or non-visual displays will not receive the information. For example, 'Press the red button' is not much use to someone with red-green colour blindness.

When foreground and background colours are too close to the same hue, they may not provide sufficient contrast when viewed using monochrome displays or by people with different types of colour deficits.

It's quite a good idea to take a screen grab of a few random pages, open them up in your graphics program, and convert them to grayscale.

3 - ‘Use mark-up and style sheets and do so properly.’

Documents must be structured correctly. Content should be presented using style sheets rather than with presentation elements and attributes. Improper use of mark-up hinders accessibility. It is much better to use <EM> and <STRONG> tags rather tha <I> and <B>.

Misusing mark-up for a presentation effect, for example using a header to change font size, makes it difficult for users with specialized software to understand the organization of a page.

Content developers must not sacrifice appropriate mark-up because a certain browser or assistive technology does not process it correctly. For example, it is appropriate to use the TABLE element in HTML to mark up tabular information provided that the table is coded correctly.

4 - ‘Clarify natural language usage.’

HTML allows developers to mark-up their documents in a way that facilitates pronunciation or interpretation of abbreviated or foreign text. When content developers mark up natural language changes in a document, speech synthesizers and Braille devices can automatically switch to the new language, making the document more accessible to multilingual users.

Content developers should identify the predominant natural language of a document's content (through mark-up or HTTP headers). Content developers should also provide explanations of abbreviations and acronyms.

In addition to helping assistive technologies, natural language mark-up allows search engines to find key words and identify documents in a desired language. Natural language mark-up also improves readability of the Web for all people, including those with learning disabilities, cognitive disabilities, or people who are deaf.

When abbreviations and natural language changes are not identified, they may be indecipherable when machine-spoken or Brailled.

5 - ‘Create tables that transform gracefully.’

Tables often present problems to users of screen readers irrespective of their purpose. It is important that tables are coded so that they linearise correctly. A great way to check how pages look when linearised is to experiment with the settings under "Page style", especially the "User mode", in the Opera browser. Web designers can unchecked "Tables" and see if their Web pages transform gracefully when they are linearised.

Incidentally, Opera is currently only $39 but there is also a free version which includes advertisments.

Tables should primarily be used to mark up tabular information although many content developers use tables to lay out pages; this is a contentious issue.

6 - ‘Ensure that pages featuring new technologies transform gracefully.’

Designers should ensure that pages are accessible even when newer technologies are not supported or are turned off. Although content developers are encouraged to use new technologies that solve problems raised by existing technologies, they should know how to make their pages still work with older browsers and people who choose to turn off features.

7 - ‘Ensure user control of time-sensitive content changes.’

Developers should ensure that moving, blinking, scrolling, or auto-updating objects or pages can be paused or stopped. The BLINK and MARQUEE elements are not defined in any W3C HTML specification and should never be used.

Some people with cognitive or visual disabilities are unable to read moving text quickly enough, or at all. Moreover, screen readers are unable to read moving text.

Movement can also cause such a distraction that the rest of the page becomes unreadable for people with cognitive disabilities.

People with physical disabilities might not be able to move quickly or accurately enough to interact with moving objects.

8 - ‘ Ensure direct accessibility of embedded user interfaces.’

Embedded objects, including items such as Windows Media files or QuickTime movies, are often presented within their own interface. These interfaces must be accessible. If the interface of the embedded object cannot be made accessible, an alternative accessible solution must be provided.

9 - ‘ Design for device-independence.’

Developers should create pages that allow users access via a variety of input devices.

Device-independence means that the user may interact with a Web site with their preferred input or output device. Examples of such devices include; mouse, keyboard, voice and head wand.

Generally, pages that allow keyboard access are also accessible through other speech input devices.

10 - ‘ Use interim solutions.’

Pages should be constructed so that assistive technologies and older browsers will operate correctly.

For example, older screen readers read lists of consecutive links as one long link. These active elements are therefore difficult or impossible to access unless the links are separated by something other than white space, for example a transparent gif.

Again, this is a contentious issue. How old is an old browser? Many developers design for version 4 browsers and above. Some designers totally ignore version 4 browsers. I guess it depends to a certain extent on your target market.

11 - ‘Use W3C technologies and guidelines.’

Web sites should be constructed using W3C technologies and guidelines. When this is not possible, or doing so results in material that does not transform gracefully, an alternative accessible version of the content should be provided.

Many non-W3C formats (e.g., PDF, Shockwave, etc.) require viewing with either plug-ins or stand-alone applications. Often, these formats cannot be viewed or navigated with standard Web access or screen reading tools. Non-W3C formats should be converted to HTML/XHTML although this does not always create an accessible document. Each page should be validated for accessibility and usability after the conversion process.

Avoiding non-W3C and non-standard features (proprietary elements, attributes, properties, and extensions) will tend to make pages more accessible to more people using a wider variety of hardware and software. When proprietary or inaccessible technologies must be used, equivalent accessible pages must be provided. Even when W3C technologies are used, they must be used in accordance with accessibility guidelines.

If a page does not easily convert, developers should either revise the page until its original content converts properly or provide an HTML or plain text version.

12 - ‘ Provide context and orientation information.’

Complex relationships between different parts of a page may be difficult for people with cognitive disabilities and people with visual disabilities to understand. Therefore, developers should provide context and orientation information to help users understand complex pages. This information is useful for all users.

For example, each form element should include a label which make it obvious that it corresponds to a particular element. If you use frames make sure that each frame is titled correctly.

13 - ‘ Provide clear navigation mechanisms.’

Clear and consistent navigation systems are important to people with cognitive disabilities or blindness, and benefit all users. Developers should provide a clear and consistent navigation system. This will ensure that users will be able to find the information they are seeking easily.

14 - ‘ Ensure that documents are clear and simple.’

Consistent page layout, recognizable graphics, and easy to understand language benefits all users. In particular, they help people with cognitive disabilities or those who have difficulty reading. It is important to ensure that images have text equivalents for people who are blind or have low vision, and for any user who cannot or has chosen not to view graphics.

Using clear and simple language promotes effective communication and is particularly important for those users whose first language is not the language of the Web page.


The WCAG guidelines can seem overwhelming, confusing and sometimes contradictory. Learning to create accessible web pages can be difficult and time consuming but the benefits to potentially millions of people are well worth it. I believe that anyone with even a basic understanding of (X)HTML can learn and apply accessibility principles and concepts. To this end I will be looking at each of the WCAG guidelines in future articles.

Back to Article Index

Tutorial Index


Dreamweaver Tutorials

Dreamweaver FAQ

Dreamweaver MX Zone

The Patty Site

welcome | name | hosting | design | content | promote | update | showcase | support
about us | general | articles | accessibility | sitemap | enquiries | feedback | training | consultancy

Welcome Showcase Support Update Promote Content Design Hosting Name