Guidelines for Web Accessibility - Printable Version

Contents

Technology Introduction

These guidelines cover all information and services delivered via the World Wide Web or using HTML, including web sites and online applications.

If the product or service combines web delivery or HTML with other technologies, then also refer to the guidelines for those other technologies. For example, if you are delivering web-based information or services through a public kiosk, you should also follow the Public Access Terminals Accessibility Guidelines.

Guidelines Introduction

The National Disability Authority (NDA) have adopted the Web Content Accessibility Guidelines 1.0 from the Web Accessibility Initiative (WAI).

To help make them easy to understand and use, the NDA have added the following:

  • Explanation and help for each guideline ("checkpoint" in WAI language)
  • A list of simplified guideline statements
  • A numbering system based on priority

The simplified guideline statements are listed on this page. Each has a link to its explanation and help, which includes the full WAI checkpoint text and a link to the appropriate page on the WAI web site.

The simplified statements, additional explanation and help provided by the NDA have not been endorsed by the World Wide Web Consortium. In case of any perceived contradictions, WAI statements and explanations should be accepted as definitive in all cases.The Web Content Accessibility Guidelines 1.0 are copyright 1999 W3C (MIT, INRIA, Keio), All Rights Reserved. See status.

Priority 1

Following priority 1 will make it possible for all groups to use the site. For some groups, this is the basic requirement to enable them to access the information.

1.1 Provide a text equivalent for every non-text element

WAI Checkpoint 1.1

Full WAI text: "Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video."

All information must be presented in text. This means that if any other media are used, such as images, the information they contain should be repeated in a text description. This description must be 'equivalent', meaning that it must convey the same information as the object it is describing. "alt" and "longdesc" are techniques for creating text-equivalents (see Directions and Techniques, below).The most common examples of non-text elements are images, animations, movies and sounds. Images may consist of artwork, photographs and coloured fills or spacers. However, they may also be drawings of text, used for titles, headings or company logos. In this case, they are not text. Text means only what is called "real text", and is made up of ASCII or unicode characters. This does not include drawings of text. Similarly, images used for buttons must also have a text equivalent, since they do not contain real text.Image maps are images which are made up of many parts, each of which is a separate graphical button or link.

ASCII art is the name given to pictures that are made up of many text characters, in the same way that a newspaper image is made up of many dots. The resulting picture has a meaning that cannot be deduced from the characters or dots. This meaning must be presented in an alternative text description. The name "ASCII" is the name of a common character encoding system used by computers.Programmatic objects, such as scripts and applets, are another type of non-text element. These are pieces of functionality written in languages other than HTML, to provide dynamic or interactive behaviour ranging from simple visual effects to mini applications. Examples include pop-up menus coded in DHTML, scrolling "tickers" and interactive applications such as tax calculators or games written in Java or Macromedia Flash. Any effect or functionality can potentially be provided by using a script or applet.Sounds include downloadable or streaming speech, audio cues, alert tones and the audio track on a video.Not all users can access or use these elements directly and will therefore require that the equivalent information or functionality is provided in text format. There are a variety of HTML techniques which can be used to provide equivalent information, including "alt" and "longdesc", both of which can be used supplement visual images with text.

Rationale

For some users, text is the only medium they can access. Someone who is blind cannot see the screen so they cannot read information which is provided in an image. If titles are presented as images, for visual appeal, users who are blind will not be able to read them and will miss a lot of important information. If images are used for buttons and navigation links, blind users may not be able to use or navigate the site at all. Information presented in pictures, graphs, charts or photographs will also be unavailable to users who are blind unless there are text equivalents.

Visually impaired users often use a screen reader, a program that interprets the text contents of the screen and outputs this either to a speech synthesiser or a Braille display. If non-text elements have text equivalents, the screen reader can read those. If there is no text equivalent, the screen reader will inform the user that there is an element there but not tell them anything about it, except perhaps the file name.

Someone who is deaf cannot hear warning sounds, narration or other audio information. However, they may be able to read text equivalents.

Many users have old equipment or slow modems and connect via continually metered telephone lines. These users often turn off image downloading to save time and money.

Directions and Techniques

Use Alt text

For simple non-text objects, such as pictures and graphical titles or buttons, you should specify a text description using the HTML "Alt" attribute. "Alt" stands for "alternative".

The alt text should be carefully worded so that it provides equivalent information. Unless the alt text effectively conveys the information an image displays, it will be ineffective. If you use alt text to provide text equivalents for images used as links, the text should make sense as a link title when read out of context. For images that are purely decorative and contain no information, such as spacers, lines and fills, use null alt text (described below).See the WAI recommended techniques for Using alt text for providing equivalent text content for images and Providing text equivalents for applets and programmatic objects.

Use null Alt text for objects that contain no information

For images that are purely decorative and contain no information, such as spacers, bullets, lines and fills, use the null value for the Alt text (Alt=""). This will be ignored by most assistive technologies such as screen readers and avoids the user being bombarded with hundreds of useless descriptions such as "a spacer, a spacer, a blue line, bullet, bullet, bullet...". Note that null alt text has no characters between the quotes. This is not the same as Alt=" ", which contains a space and is not therefore null Alt text. Assistive technologies may not ignore objects with Alt text which contains a space.

See the WAI recommended techniques for Using images as bullet points and Using images as links.

Provide a long description if Alt text will not be adequate

Alt text is not really useful for explaining information that is too complex to describe in only a few words. For example, if you were to display a graph showing population growth in three countries (France, Germany and Spain) from 1995 to 2001, you could use Alt text to give a basic description of the graph, such as:

"Graph showing population growth in France, Germany and Spain, 1995 to 2001" -

However, the information contained in the graph may be quite complex and may therefore require a longer description. It may show individual colour-coded line plots for each country, allowing the user to quickly identify overall trends and make comparisons.

This is beyond the capabilities of Alt and in this case, you should use the HTML "Longdesc" tag or a "D" link. Both techniques allow users to access a separate, detailed text description of the content. Longdesc, though part of the HTML specification, is not widely suported by browsers. The alternative "D" link technique involves inserting, beside the image, a link which is presented as a capital "D". The target of this link should be a separate web page which displays the long description in text-only format. Once the user has read this, they can then return to the page with the image. "Longdesc" stands for "long description".

See the WAI recommended techniques for Providing long descriptions with Longdesc and the "D" link.

Provide a text equivalent for each active link contained in an image map

See the WAI recommended technique for Providing text equivalents of links contained in image maps. Note that the link should be a client-side link to work with this technique.

How you could check for this:

Switch off image downloading in your browser

This will show you how the page looks without images. You should be able to see alt text where images no longer display. Ask yourself whether the alt text is appropriate or not.

Switch off scripts and Java in your browser

This will let you see you how the page looks and works without scripts and applets. From this, you can determine whether or not it is possible to use the page without scripts and applets.

Test the page with the Bobby tool

"Bobby" is an automated testing tool, which can tell you if images on a web page have Alt text associated with them. You can get Bobby at http://www.cast.org/bobby. Note, however, that Bobby will not tell you if the Alt text is appropriate or not. You must decide this yourself. Bobby has it's limitations and you should take time to read the documentation in the "How to Read the Bobby Report" and FAQs section on the Bobby website.

- View WAI Checkpoint 1.1

1.2 Ensure that information does not rely on colour perception

WAI Checkpoint 2.1

Full WAI text: "Ensure that all information conveyed with colour is also available without colour, for example from context or markup."

Colour is useful for conveying information but you should not rely on colour as the only way to communicate meaning. Use more than just colour to communicate information by taking advantage of labels, style effects, etc.

Rationale

Not everyone can easily perceive differences in colour and they would find it difficult to understand information which is communicated by colour alone. For example, imagine two buttons on a screen, both are identical in terms of size and shape. One is green, the other red. Clicking the red button will destroy the user's computer. If the user can't distinguish between the colours and there are no labels on the buttons, they can't make the correct choice.

Users find it hard to perceive colours if they work with poor quality or monochrome display screens or if they are colour-blind.

Similarly, it is difficult to read text displayed on a background colour which is very close in terms of either hue or contrast. Some colour combinations, such as red text on a green background are also difficult to differentiate.

Screen grab of a web page with unlabelled red and green buttons. The instruction reads 'FOR SLOWER CONNECTIONS CLICK GREEN BUTTON'.

Do not rely on colour alone to convey meaning
The buttons on this web page rely on the users ability to distinguish between red and green.

Directions and Techniques

Supplement information conveyed through colour with style effects

Style effects, such as typefaces, can be used to highlight differences in information.

Add labels or symbols to graphic links or buttons to communicate their function

Labels can be displayed as text which is clearly associated with a graphic link or button. The label could be in the format of text or an icon or symbol which is displayed on the graphic element. You could also use alt text to associate a label with a graphic control.

Provide link titles that make sense when read out of context

If you provide a group of links, do not rely on colour alone to communicate information about the links (e.g. "click on the red links to edit this document" followed by lists of links, all of which read "click here". Some are red.). Link titles should which make sense when read out of context, e.g. "Edit the spelling", "Edit the font styles".

How you could check for this:

Print the page on a black and white printer

This will provide some indication of how the page would look without colour. However, this is not a foolproof test. Most browsers are configured so they don?t print background colours which could be displayed behind the main body of text on the page.

View the page on a monochrome browser

This will give show how the page would look without colour and you can determine if only colour is used to communicate information.

Test with Vischeck

Vischeck is a piece of software which can emulate how a page would appear to a user who is colour blind. You can get Vischeck at http://vischeck.com Go to Vischeck.com

- View WAI Checkpoint 2.1

1.3 Avoid causing the screen to flicker

WAI checkpoint 7.1

Full WAI text: "Until user agents allow users to control flickering, avoid causing the screen to flicker."

A user agent is a piece of software for accessing Web content. User agents could be desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software.

It is possible to cause the screen to flicker by inserting commands in the underlying HTML of a web page, usually to create a visual effect.

Not all user agents allow the user to control the rate at which the screen flickers. Until such time as they do, you must not create flickering effects.

Rationale

It is difficult to concentrate on a flickering screen. Screen flicker can also trigger epileptic seizures. People with photosensitive epilepsy can have seizures triggered by flickering or flashing in the 2 to 60 flashes per second (Hertz) range, with a peak sensitivity at 20 flashes per second as well as quick changes from dark to light (like strobe lights).

Directions and Techniques

Ensure that screen flicker is within a safe range

Keep flickering to less than 2 flashes per second (Hertz) and do not change quickly from from dark to light.

Provide a mechanism or control for freezing flicker or movement

If you create flicker effects using Java applets or other techniques, you should provide an obvious control which allows the user to freeze movement or disable the flicker effect.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 7.1

1.4 Provide an auditory description of the visual information in multimedia presentations

WAI checkpoint 1.3

Full WAI text: "Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation."

A user agent is a piece of software for accessing Web content. User agents could be desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software.

Multimedia is information presented in a combination of forms, including audio (speech, sounds, music, etc.) and images (video, text, graphics, pictures, animations, movies, etc.). On the web, multimedia information can be presented through the web browser in any of these formats or in combinations. Animations created with a product like Macromedia Flash might combine images and audio. An instructional Flash animation about web design could include images of a website on a computer monitor, a narrative or voice-over and images of a person using software. The images are contained on the image track, while the voice-over is contained on the audio track.An auditory description is a spoken description of the content of a multimedia file. In the case of a video, the auditory description would describe in speech, the visual content of the video, including images, actions, body language, changes of scenes, etc. The auditory description is typically synchronised with the audio content of the file. In the instructional movie on web design, the audio description would be inserted between silences in the voice-over. It could inform the user if the instructor was demonstrating a feature of the design software, or if the voice-over was referring to the image of the website on screen.The auditory description can be presented as pre-recorded or synthesised speech.A text equivalent of the visual track is "equivalent" when both fulfil essentially the same function or purpose. The text equivalent may be a description of the visual track, i.e., what it looks like or sounds like. It is presented in text format. Most browsers do not automatically read out the text equivalent of a visual track and until such time as they do, you must present the auditory description in both text and audio formats.

Rationale

Users who can't see the visual content of a multimedia presentation require auditory description. This is important when users can't get close enough to the display monitor, have poor eyesight or they could be blind.

Users who can't hear the audio track require a text description. They may be working in a quiet environment, like a library, with the sound turned down or they might be in a noisy environment where the sound is obscured by noise. They could have poor hearing or could be deaf.

Some accessibility features are best handled by the user agent. Ideally, users should be able to set it to ignore any commands, which could be embedded in the underlying HTML that might cause the content of a web page to be rendered unusable.

Some newer browsers provide support for accessibility controls but not all browsers are the same. There are no widely adopted standardised, consistent controls to improve accessibility.

Ideally, all user agents would detect whether the equivalent of a visual track is provided in text format and would automatically read it aloud to the user. However, this is not the case and the requirement to ensure that a website is usable, without relying on proprietary browser features is placed on the developer until the time comes when browser behaviour is more standardised.

Until then, it is necessary to provide an auditory equivalent that is read aloud and embedded in the audio track of the multimedia file.

Directions and Techniques

Provide text descriptions for video, as captions

Captions are text equivalents of the visual content of a video. They are provided synchronously with the video content. Some media formats (e.g. Quicktime and SMIL) allow captions and descriptions to be added to the multimedia clip. If you are using these formats, you should take advantage of these features.

How you could check for this:

View the presentation with the monitor turned off or while looking away from the monitor

If you can't follow the presentation with sound only, then you need an audio description.

- View WAI checkpoint 1.3

1.5 For multimedia, ensure that timing of alternative descriptions is synchronised with the presentation

WAI checkpoint 1.4

Full WAI text: "For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation."

Movies and animations are examples of time-based presentations, where content constantly changes from moment to moment. Captions or auditory descriptions are examples of equivalent alternatives. They are non-visual descriptions that communicate the content of the visual or auditory part of a presentation. Alternative equivalents should be inserted in appropriate gaps or silences in auditory or textual content or they should be positioned so they do not interfere with the visual content of a presentation.

Rationale

Users who can't see the visual content of a multimedia presentation require an auditory description because they can't get close enough to the display monitor, have poor eyesight or they could be blind.

Users who can't hear the audio track require a text description. They may be working in a quiet environment, like a library, with the sound turned down or they might be in a noisy environment where the sound is obscured by noise. They could have poor hearing or could be deaf.

Movies, videos and animations often include audio content. This could be a voice over or important sound effects. They may also include important text content, like the name and job title of a person in an interview or dialogue subtitles in a translated film. The alternative equivalents - be they captions or auditory descriptions - should not -blot out' or interfere with this important content.

Directions and Techniques

There are no specific techniques recommended for this guideline.

How you could check for this:

View the presentation with captions activated

Open the presentation in a media player which supports captions and enable the caption feature to see if captions are present and whether or not they interfere with important visual content, such as on screen text, subtitles, graphs, etc.

Listen to the audio description of the presentation without looking at the screen

When you do this, listen to see if the auditory description interferes with the audio content of the presentation. Looking away from the screen, or turning it off will mean that you have to interpret the presentation without the aid of the visual information.

- View WAI checkpoint 1.4

1.6 Use the clearest and simplest language appropriate

WAI checkpoint 14.1

Full WAI text: "Use the clearest and simplest language appropriate for a site's content."

Unless a site features very specialised content requiring specialised terminology, the language used to communicate information should be understandable by the widest possible audience.

Rationale

Overuse of jargon makes content difficult to understand. Complex, or long sentences and paragraphs are difficult to read and comprehend. Users do not like reading large tracts of text online and you should therefore structure content so that it can be -skimmed' easily. Skimming involves reading quickly over headings, titles and bullet lists to get a feel for the broad content of a page before reading it in detail.

Directions and Techniques

Create a style guide for written content

A style guide will help you to consistently provide accessible, easy to understand content by providing content contributors with direction on writing style, tone of voice and language usage.

Review content to ensure that it is clear and simple

Set up an editorial procedure to ensure that content is free of jargon and written to facilitate reading online, before it is published.

Consider providing a glossary of terms

If there are specialised terms which must be used on the site, provide a glossary which allows users to look up the meaning of difficult or unfamiliar words.

Use clear, concise headings and link titles

Headings provide context and help people to determine the structure of written information. Titles, including link titles, should provide an overview or a clue of the associated content.

Break content into small, easily read 'chunks'

Use paragraphs, bullet lists and sub headings to break content into small chunks which are easier to read and scan.

Use clear, simple language in audio tracks

If you provide information through audio or video, ensure that the language is simple and clear.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 14.1

1.7 Identify language changes in text

WAI checkpoint 4.1

Full WAI text: "Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions)."

Natural language refers to spoken, written or signed languages, such as English, Irish, Irish Sign Language and Braille. The predominant natural language of a web page should be identified in the underlying HTML. If there are passages of text contained in a page, which are presented in a different language to the predominant natural language you should flag the change. This also applies to text equivalents, such as alt text or captions, for information presented in visual or audio format.

Rationale

Speech synthesisers and Braille devices need to be told what the natural language is so they can present the information using the correct pronunciation. Failing to identify the natural language could cause these devices to mispronounce words, making the information difficult to undestand.

Identifying the natural language also facilitates automated translators: software or machines capable of reading the contents of a page and translating it into another language.

Directions and Techniques

WAI recommended technique on identifying changes in the natural language

Identify changes in the natural language with the "lang" attribute. This HTML attribute describes the natural language of the text. Use it to identify the primary natural language and any changes to the natural language. Follow the WAI recommendations on using the LANG attribute

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 4.1

1.8 Ensure that equivalents for dynamic content are updated when the dynamic content changes

WAI checkpoint 6.2

Full WAI text: "Ensure that equivalents for dynamic content are updated when the dynamic content changes."

Dynamic content is information which is updated in real time or which changes every time it is accessed. It could be text content which is held on a database and is presented to the user as it 'comes live' and is then uploaded in real time to a web page. Video, audio and content presented through scripts and applets is also dynamic. A continually scrolling news ticker, presented through a script or applet, is dynamic if the headlines are updated in real time.

Information presented in dynamic features must also be repeated in an equally up to date equivalent version.

Rationale

Many methods for delivering dynamic content rely on newer technologies which may be inaccessible to users of older equipment.

Some methods cause problems for users with limited mobility, reading difficulties or poor sight. This can happen when dynamic content changes continually or automatically refreshes in only one area of a web page, e.g. a scrolling news ticker. This type of presentation causes problems for screen readers. Users with limited mobility may find it difficult to click on the moving links. Users with poor sight or reading difficulties find it difficult to read moving text.Frames are another method, often used to present dynamic content. Frames are used to divide the page into sections. For example, the left hand side of a web page could present navigation links in one frame (the navigation frame), while the main content is presented in another (the content frame). The navigation frame always presents the same content but the information in the content frame is dynamic because it changes depending on the link selected from the navigation frame.If these methods are used to present dynamic information, it is good practice to provide an equivalent version, possibly on another page. However, this version must be as timely and up to date as the dynamic version. If it isn't, users will be misinformed.

Directions and Techniques

Provide text equivalents for applets and programmatic objects

Follow the WAI recommended techniques for providing WAI recommended techniques for providing equivalents of content and functionality presented through applets and other programmatic objects

Provide text equivalents of frames

Frame contents and the relationships between frames should make sense. Follow WAI recommendations for providing text equivalents of frames

Provide text equivalents of scripts

Follow WAI recommended techniques for providing equivalents of content and functionality presented through scripts.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 6.2

1.9 For data tables, identify row and column headers

WAI checkpoint 5.1

Full WAI text: "For data tables, identify row and column headers"

A data table contains information which is presented in tabular format, e.g. financial accounts, timetables, etc. Row and column headers describe the contents of table cells, providing context for the information contained in the table as a whole.

Headers must be defined by inserting the correct HTML attribute, which indicates the table structure in a non-visual way.

Note: Tables are also used to control the layout of images and text on a web page. Tables used solely for this purpose are not data tables and do not require row and column headers.

Rationale

People who can scan a table visually make sense of the information structure by visually comparing row and column headers with the contents of the table cells. However, users of text-only browsers or screen readers rely on the headers to gain an understanding of the table structure.

If headers are not correctly identified in the underlying HTML, the contextual information required to make sense of the structure of a table will be lost when it is read by a text only browser or screen reader, rendering the information in the table useless.

Directions and Techniques

Use the TH and TD HTML attributes to associate table data with table headers

TD is used to create a data cell in a table. TH is used to create column headers. Associate the content in the data cells with the "headers" attribute. TD is used to create a data cell in a table. TH is used to create column headers. Associate the content in the data cells with the 'headers' attribute. See the WAI recommended techniques on using TH and TD to identify table headers

How you could check for this:

Test the page with a screen reader or audio browser

Doing this will tell you if the page is correctly coded as the speech synthesiser will read the contents of the table with the correct structure.

- View WAI checkpoint 5.1

1.10 For complex data tables, use mark-up to associate data cells and header cells

WAI checkpoint 5.2

Full WAI text: "For data tables that have two or more logical levels of row or column headers, use mark-up to associate data cells and header cells."

A data table contains information which is presented in tabular format, e.g. financial accounts, timetables, etc. Row and column headers describe the contents of table cells, providing context for the information contained in the table as a whole.

Headers must be defined by inserting the correct HTML attribute, which indicates the table structure in a non-visual way.

When the information contained in a table is organised in a structural hierarchy with headings and subheadings, it is said to have 'logical levels'. Each heading and subheading corresponds to a logical level.

You must define the structural hierarchy of the headers and their relationship with the data cells of a table.

Note: Tables are also used to control the layout of images and text on a web page. Tables used solely for this purpose are not data tables and do not require row and column headers.

Rationale

People who can scan a table visually make sense of the information structure by visually comparing row and column headers with the contents of the table cells. However, users of text-only browsers or screen readers rely on the headers to gain an understanding of the table structure.

If the relationship between headers and data cells is not correctly identified in the underlying HTML, the contextual information required to make sense of the structure of a table will be lost when it is read by a text only browser or screen reader, rendering the information in the table useless.

Directions and Techniques

Use the correct HTML mark-up for building tables

When writing HTML, use THEAD, TFOOT, and TBODY to group rows, COL and COLGROUP to group columns, and the "axis", "scope", and "headers" attributes, to describe more complex relationships among data. See the WAI recommended techniques on good HTML practice for defining logical relationships in tables

How you could check for this:

Test the page with a screen reader or an audio web browser

Doing this will tell you if the page is correctly coded as the speech synthesiser will read the contents of the table with the correct structure.

- View WAI checkpoint 5.2

1.11 Add titles to frames

WAI checkpoint 12.1

Full WAI text: "Title each frame to facilitate frame identification and navigation."

Frames allow the designer to break a web page into different pieces, each containing a different HTML file. Frames are often used is to break the page into two sections - one containing information which does not change as the user travels through the site and the other presents more dynamic information. A typical example is where the main navigation for a site is presented in a frame on the left side of the page, while content is presented in another frame on the right.

In this case, the navigation links are held in one HTML file on the left of the page while the content is held in another HTML file, which is called up depending on the link selected from the left frame. Clicking a link on the left essentially causes a new page to open in the right hand side of the browser window.Each frame should have a title, even though this is not displayed visually.

Rationale

Users of older browsers or screen readers have difficulty in navigating web pages with frames. A user who can visually scan the page to determine the relationship of the page elements might not even notice if frames are used and will easily envisage the page structure but users who can't see the entire page don't have this ability.

For example, if a screen reader user opens a page with frames, they are presented with a list of the frames that make up the page. If the frames don't have titles, the user is presented with a list of file names, which have no meaning, e.g. -Frame: a'. The lack of useful information about the contents of the frame forces the user to open each frame, one by one, review their contents and figure out how it relates to the other frames on the page. This is frustrating and time consuming.

Directions and Techniques

Do not use frames purely for presentation purposes

Frames can offer benefits from a functional point of view but if the only reason you have for using them is purely aesthetic, then it is best not to use them. Most of the accessibility problems caused by the use of frames arise because they are a structural element, inappropriately used for visual layout.

Use the "title" attribute to name frames

When you code the HTML for frames, ensure that the 'title' attribute is used to provide a name for each frame. Treat frame titles or names like link titles and ensure that they have meaningful names which provide users with a good idea about the content of the frame, e.g. "main site navigation" is a better name than "nav". See WAI recommended techniques for using the "title" attribute to name frames

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 12.1

1.12 Ensure that documents can be read without style sheets

WAI checkpoint 6.1

Full WAI text: "Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document."

Style sheets specify the presentation of a document on the web. They can be used to control things like the typefaces, font sizes, colours and the positioning of elements on a page. It should be possible to read the content of the page, in the correct logical order, without style sheet support.

Rationale

Style sheets are not consistently supported by different browsers and some browsers do not support them at all. If a visual layout that communicates the structure of information is controlled with style sheets and the page is viewed on a browser which does not support them, the logical structure and the information will be meaningless.

Some users over-ride the default style sheet created by the designer to replace it with another, which is more suited to their needs. For example, a user may need larger fonts, or a different colour scheme because this makes reading easier. The page may not look as nice as the designer intended but is still legible and meaningful

This guideline introduces the concept of -graceful degradation', also called -graceful transformation'. A web site degrades gracefully when the core information and functionality is available, although perhaps not as elegantly as it could be, across a range of different browser types.

Directions and Techniques

Follow WAI recommended CSS techniques for rules and borders

Use style sheets to generate content such as paragraph numbers, which help users of screen readers to keep track of their position in a document. This technique generates the content so that it is "hidden" or not presented visually. WAI recommended Cascading Style Sheet (CSS) techniques for generating content

WAI recommended CSS techniques for rules and borders

Rules and borders may convey the notion of "separation" to sighted users but that meaning cannot be inferred out of a visual context. This technique shows how to create rules and borders using Cascading Style Sheets (CSS) and how to indicate the logical order using styles.
WAI recommended techniques for rules and borders with stylesheets

Follow WAI recommended CSS techniques for using style sheet positioning and mark-up to transform gracefully

Rules and borders may convey the notion of "separation" to visually enabled users but that meaning cannot be inferred out of a visual context. This technique shows how to create rules and borders using (Cascading Style Sheets (CSS) and how to indicate the logical order using styles. WAI recommended techniques for style sheet positioning

Follow WAI recommended techniques for using style sheets to control layout and presentation which transforms gracefully

Create style sheets which control layout and presentation in a logical order, even if style sheets are not supported or are turned off in the user's browser using the WAI recommended techniques for style sheets and layout.

Use the WAI style sheet validator

This software tool can be used to validate CSS 1 and CSS 2. Open the W3C CSS Validator

How you could check for this:

Test the website on different browsers and platforms

Test the website with different browsers to determine if the site works on browsers with different style sheet capabilities. For example, test on the Macintosh and PC platforms with different browsers like Internet Explorer, Opera, Netscape and a text-only browser like Lynx.

Test the website on older browsers

Older browsers may not support style sheets so testing the web site with an older browser will show if the information and functionality is accessible to older browsers.

Disable style sheet capability on your browser and open the web site

This will show you what the site looks like and whether it functions without style sheets enabled.

Test style sheets with the W3C stylesheet validator

This software tool can be used to validate CSS 1 and CSS 2. Test a stylesheet with the W3C CSS Validator

- View WAI checkpoint 6.1

1.13 Provide text links to emulate server-side image maps

WAI Checkpoint 1.2

Full WAI text: "Provide redundant text links for each active region of a server-side image map."

Image maps are images which are made up of many parts, each of which is a separate graphical button or link. To follow a link on a server-side image map, the user clicks on a point on the image with the mouse. The geometric co-ordinates of the point are sent to the server where the web page is hosted and the user is directed to a page corresponding to a link associated with that point.

Server-side image maps are divided into portions called 'active regions'. These regions correspond with links to different destinations and are often irregular shapes. For example, a map of Ireland could be presented to the user who would then have to click on a county to see more information about that area. In this case, the map of Ireland is a server-side image map and each county is an active region on the image map.Redundant text links are presented in text format and correspond to the links contained in the active regions of the image map.

Rationale

Server-side image maps do not provide adequate support for alt text as it can't be provided for each active region. Alt text is only applied to the map as a whole, which means that they can't be used on non-graphic web browsers or if images are disabled on a graphic browser, thereby preventing users from accessing any of the links.

Also, server-side image maps rely on -point and click' interaction with a mouse, making them unusable by keyboard only navigation, i.e. for users of laptops without a mouse, screen readers, touch screens or special pointing devices.

Directions and Techniques

Provide an alternative list of links after the IMG and indicate the existence and location of the alternative list

Consider these WAI recommended techniques for providing alternative links when using the OBJECT element.

If you use the OBJECT element, include redundant text links

WAI recommended technique on providing alternative links when using the OBJECT element

Ensure that redundant text links have meaningful titles

Redundant text links should make sense when read out of context, e.g. if you were to present population figures for counties in Ireland through an image map in the shape of the map of Ireland, where each county is an active region, the redundant text links should provide a clue about the consequence of following the link. You might say "Population of Limerick" as opposed to just "Limerick". This provides people who can't see the image map with helpful contextual information.

If a list of text links is not appropriate, provide the list in a combo-box

If a long list of text only links does not seem appropriate on the web page, consider using a combo box but ensure that it is programmed in a way that makes it accessible.

Provide alt text for all active regions in a client side image map

When you provide alt text for the active regions, remember that they should make sense as link titles when read out of context. A user who has to rely on the alt text to use the image map will need helpful contextual information from the link titles. CAST recommended techniques for alt text and client side image maps

How you could check for this:

Try using the site with the mouse plugged out

If you can't navigate the site with the mouse plugged out, you will need to insert redundant text links.

Test the site with a text only browser

A text only browser, such as Lynx, cannot recognise images and will present the text only. Pages with server-side image maps will be unusable unless redundant text links are provided.

- View WAI Checkpoint 1.2

1.14 Use client-side image maps rather than server-side image maps where possible

WAI checkpoint 9.1

Full WAI text: "Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape."

Image maps are images which are made up of many parts, each of which is a separate graphical button or link. The different parts are called 'active regions'.

With server-side image maps, the user clicks on a point on the image map and the coordinates of the point they click on are sent to an image map processing application on the server where the site is hosted. With client-side image maps the processing is done in the user's browser.

Client side image maps must be used, unless there is an absolute need to define the active regions with irregular shapes (as opposed to simple geometric shapes like squares or rectangles).

Rationale

Server-side image maps do not provide adequate support for alt text as it can't be provided for each active region. Alt text is only applied to the map as a whole, which means that they can't be used on non-graphic web browsers or if images are disabled on a graphic browser, thereby preventing users from accessing any of the links.

Also, server-side image maps rely on -point and click' interaction with a mouse, making them unusable by keyboard only navigation, i.e. for users of laptops without a mouse, screen readers, touch screens or special pointing devices.

However, client side image maps are not suitable for some applications. For example, a co-ordinate based geographical information system would be very difficult to present by building a client side image map from thousands of individual images, each with it's own alt text.

Directions and Techniques

There are no specific techniques recommended for this guideline.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 9.1

1.15 Ensure that scripts and applets that provide the only source of important functionality are directly accessible or compatible with assistive technologies

WAI checkpoint 8.1

Full WAI text:"Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2.]"

Scripts and applets are types of programmatic objects. These are pieces of functionality written in languages other than HTML, to provide dynamic or interactive behaviour ranging from simple visual effects to mini applications.

Some examples are enhanced functionality like pop-up menus coded in DHTML, form input validation routines written in JavaScript and interactive applications such as tax calculators or games written in Java or Macromedia Flash.

Programmatic elements should either be inherently accessible or should include features that ensure they are usable with assistive technologies.

Assistive technologies enable users to provide inputs and perceive outputs where they can't do so using technologies like the mouse, keyboard or monitor screen. For example, blind users may use a screen reader, which is a program that interprets the text contents of the screen and outputs this either to a speech synthesiser or a Braille display. Users with low acuity vision may use a screen magnifier program to enlarge a selected portion of the screen. People with motor impairments may require a special keyboard or a pointing device controlled by a joystick or by head movements.

Rationale

Ideally programmatic elements should be directly accessible so the widest audience can use them without having to resort to assistive technologies. This is not always possible, as many browsers or operating systems do not include adequate accessibility features. In this case, accessibility features which are provided in programming technologies and supported by assistive technologies should be included in programmatic elements.

Direct accessibility is desirable in situations where the user wants to access a service or information delivered through HTML pages but can't use their assistive devices or technologies because it is not practical or feasible. For example, using a screen reader to interact with a kiosk in a public place. This would be impossible because screen readers are typically installed on the user's PC and configured it to suit their needs.

Directions and Techniques

Write directly accessible applets

See WAI recommended techniques for writing directly accessible applets

If you use Java to create applets, consult the Java Look and Feel Guidelines from Sun Microsystems

Java has inherent accessibility features. Ensure that you have provided for input device independence using them. Refer to Sun guidelines on accessibility features provided in Java for details on using them.

How you could check for this:

Test programmatic elements with assistive technologies

Testing with assistive technologies such as screen readers, screen magnifiers, special pointing devices will show whether they are directly accessible or compatible with assistive technologies. You should consider testing with real users and if you do this, be sure to follow a structured user test methodology.

Test programmatic elements with keyboard only navigation
Test programmatic elements with audio browsers

- View WAI checkpoint 8.1

1.16 Ensure that pages are usable without support for scripts, applets, or other programmatic objects

WAI Checkpoint 6.3

Full WAI text: "Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page."

Users should be able to access all of the information and functionality provided on a page, even if they are unable to use any scripts, applets, or other programmatic objects that it contains.

Scripts and applets are types of programmatic objects. These are pieces of functionality written in languages other than HTML, to provide dynamic or interactive behaviour ranging from simple visual effects to mini applications. Examples include automatic redirects, pop-up menus coded in DHTML, form input validation routines written in JavaScript and interactive applications such as tax calculators or games written in Java or Macromedia Flash. Any effect or functionality can potentially be provided by using a script or applet.If it is not possible to present the page without relying on these programmatic objects, the information and functionality it contains should also be provided either in an alternative form on the same page or on a different page, using accessible methods.

Rationale

Many users do not use equipment that is capable of running scripts, applets or other programmatic objects. For example, they may have old or non-mainstream hardware and software that does not support the scripting languages or supports only earlier versions. They may be working in an environment where scripts and applets are blocked by a firewall for security reasons. They may have a physical impairment that means they are unable to use a mouse and cannot therefore interact with scripts that require mouse input. Or they may be using a form of assistive technology, such as a screen reader, which cannot access the contents of the script, applet or object. Other users may have turned off support for script handling for reasons of speed or security.

Directions and Techniques

Avoid using JavaScript: as a link target

A user agent that does not support javascript cannot do anything with this, so the link is effectively broken.

Use the NOSCRIPT element

User agents that do not support scripting will display the contents of the NOSCRIPT element.

Use server-side scripts instead of client-side scripts

If you use a client-side script and the client does not support scripting, nothing at all will happen. But in many cases, the same functionality can be achieved using a server-side script with the result returned to the client as an updated page.

Provide a text equivalent of the information

See the WAI recommended techniques for Text and non-text equivalents for applets and programmatic objects.

How you could check for this:

Turn off support for scripts and applets or use a browser that has no support

The latest versions of mainstream browsers allow you to decide whether to accept scripts or applets for security reasons. Some older browsers do not support scripts or applets at all. If turning off support for scipts and applets makes any of the functionality unusable, then the site will be inaccessible to some users.

- View WAI Checkpoint 6.3

1.17 If you cannot make a page accessible, provide an equivalent accessible page

WAI checkpoint 11.4

Full WAI text: "If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page."

If it is impossible to create an equally accessible web page, provide a link to another page, which is universally accessible and is built with technologies endorsed by the World Wide Web Consortium (W3C). This page should provide the same information or functionality as the inaccessible page but in an accessible format. Changes to content or functionality should be made to both pages simultaneously.

The World Wide Web Consortium (W3C), an independent, international body that creates Internet and programming language standards. Its recommendations and standards are highly regarded.

Rationale

It is very frustrating for users to navigate to an alternative page, only to find that content is out of date or missing. This can happen if no editorial or quality assurance process is in place to ensure that all versions of a web page are equally up to date.

If non-W3C technologies are used, the user may be forced to download plug-ins or stand-alone applications which could be inaccessible. W3C technologies include standardised versions of HTML, XML, Style sheets, multimedia and many other technologies. The W3C continually review these technologies for accessibility. They are non-proprietary, making them usable across a wide variety of browsers and user agents. By using them, you are more likely to embed accessibility in your website.

Directions and Techniques

Provide a clear link to alternative version(s) at the top of each page

Providing the link at the top of the page means that the user does not have to wade through inaccessible content to view the alternative version. You should also provide a link to allow the user to navigate back to the original version.

Use scripts to automatically detect different browsers and present appropriate versions of web pages

A 'browser detect' is a script which can detect the type of browser used by a visitor to a site. If a browser detect is used in combination with alternative versions, it is possible to present the user with a version of the page which works well in their browser. Note that it is not possible to detect if the user is using a screen reader because they are not browsers.

Consider using user profiles for frequently visited pages

If the site contains information or services which a user is likely to use on an ongoing basis, consider providing them with the option to save a profile, which would save their presentation preferences, thus avoiding the need to navigate to an alternate version with each visit.

Use server side scripts to generate alternative pages on demand

Server side scripts, such as Java servlets, or PHP can be used to create alternative presentations of a page if the user requests one through their browser. The benefit of providing alternative pages in this way is that there is no requirement to maintain different 'versions' of a website which reduces the maintenance effort and ensures that up to date content is delivered to the user, regardless of the version they select.

Provide an offline equivalent

If it is absolutely impossible to deliver an accessible page, provide an offline service, delivered by trained personnel. Provide contact details such as email, telephone number, postal address and information on getting to the location if this is needed. This way information or services can be delivered over the phone, by correspondence or in person. Because people often access the web at times outside normal office hours, you should consider offering this service on a 24-hour basis.

How you could check for this:

Compare the page in different browsers or user agents

Opening the page in different browsers, especially older browsers will show you how it renders and whether or not functionality is supported or if information is missing. If it is, then the information or functionality is not equivalent. You should also test like this with user agents - things like screen readers or kiosks. If you don't have direct access to this technology, get someone who knows how to evaluate the site to do so with these user agents.

- View WAI checkpoint 11.4

Priority 2

Following priority 2 will remove significant barriers for one or more groups.

2.1 Ensure that images have sufficient contrast for people with colour deficient vision

WAI checkpoint 2.2

Full WAI text: "Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text]."

The difference in contrast between the foreground and background colours used in any image should be sufficient for users to perceive the image correctly, including users who have impaired colour vision or who use a black and white screen.

Rationale

Not everyone can easily distinguish between close colour combinations and tones. Some users find it difficult to read content, recognise objects or select items from a list when the item and the background are similar in tone, even if the colours are different. This particularly affects older users or those who have some form of colour-blindness.

Users may also find it hard to distinguish between colours if they use a poor quality or monochrome screen.

Colour has three attributes which determine how people perceive it - hue, lightness and saturation. Hue is the basic perceived colour, essentially the name of the colour - a scarf could be "red". Lightness is tonal quality - the scarf could be red but described as "dark red". Saturation is the amount of colour - the scarf is "very red". As colours become less saturated, they move toward being either black or white.Colour schemes which achieve clear differentiation in all three attributes provide the greatest contrast. Peoples' perception of the contrast of colour is bound up in their ability to perceive any or all of the three attributes, and this varies greatly. You should never assume that if you can clearly perceive a colour combination as being a good contrast then others will too.

Directions and Techniques

Understand how colour contrast is perceived

For more information on how colour choice affects perceived contrast, see Lighthouse.

Refer to the WAI recommended techniques for this guideline

See the WAI recommended techniques for providing sufficient contrast

How you could check for this:

View the page on a monochrome monitor

This will show how the page would look without colour and you can determine if colour differentiation is essential for understanding the information.

Print the page on a black and white printer

This will provide some indication of how the page would look without colour. However, this is not a foolproof test. Most browsers are configured so they do not print background colours which could be displayed behind the main body of text on the page.

Test with Vischeck

Vischeck is a piece of software which can emulate how an image or page would appear to a user who is colour blind. You can get Vischeck at http://www.vischeck.com

- View WAI checkpoint 2.2

2.2 Avoid causing content to blink

WAI checkpoint 7.2

Full WAI text: "Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off)."

User agents are software which people use to access Web content. These include graphical browsers, text-only browsers, voice browsers, mobile phones, multimedia players, plug-ins and assistive technologies such as screen readers, screen magnifiers and voice recognition software.

It is possible to cause content to blink or flash by inserting commands to do this into the web page. This is usually done to create a novel effect, but should be avoided at present, since not all user agents allow the user to control the rate of blinking or to disable it.

Rationale

Flickering may induce epileptic seizures in users if it occurs regularly at a particular rate.

It is also difficult to read content which is flashing on and off or to read content when something else on the page is flashing. Blinking is particularly distracting for users who have limited reading ability or difficulty concentrating because of noise, stress or a learning disorder.

Directions and Techniques

Ensure that screen flicker is within a safe range

Keep blinking to less than 2 flashes per second (Hertz) and do not change quickly from from dark to light.

Provide a mechanism or control for controlling or disabling blinking

If you create blinking effects using Java applets or other techniques, you should provide an obvious control which allows the user to freeze movement or disable the flicker effect.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 7.2

2.3 Avoid movement in content

WAI checkpoint 7.3

Full WAI text: "Until user agents allow users to freeze moving content, avoid movement in pages."

User agents are software which people use to access Web content. User agents could be desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software.

Examples of moving content include animations or continually scrolling news tickers. Not all user agents allow users to freeze moving content. Until such time as they do, avoid presenting it on web pages.

Rationale

Content that moves continuously is distracting and annoying for most users. Users who read visually often hide animations or moving text from view by covering it with their hands, a piece of paper or by scrolling the page so it can't be seen.

Links that are presented as a continually scrolling list require users to read the list and decide to follow one link before it disappears. This is tedious because many people prefer to read the entire list before making a choice. Clicking on moving links can be difficult for users with limited dexterity.Screen reader users find moving content difficult or impossible to use because screen readers do not cope with content that changes continually within the browser window.Users with reading or concentration difficulties find moving content difficult to comprehend and users with poor vision find it very hard to focus on moving content.

"I hate scrolling displays. They're nice because they are dynamic and they get your attention but I can't actually read them because I can't focus on moving text." - user with low vision

Directions and Techniques

There are no specific techniques recommended for this guideline.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 7.3

2.4 Ensure that dynamic content is accessible or provide an alternative presentation or page

WAI checkpoint 6.5

Full WAI text: "Ensure that dynamic content is accessible or provide an alternative presentation or page."

Dynamic content is information on the page which is updated in real time. For example, breaking news which is uploaded "live" from a dynamic database in real time. Video, audio and content which is presented through scripts and applets is also dynamic. An example of dynamic content presented through a script or applet is where news headlines are presented as a continually updated scrolling ticker. Frames are also a form of dynamic content since a frame can be reloaded without a page transition or refresh.

If a web page contains dynamic information, then the dynamic content should be delivered in a way that makes it accessible. Failing that, users should be provided with a means to navigate to another page where the same information is presented in an accessible format.

Rationale

Dynamic content may be inaccessible for a variety of reasons. Some types of dynamic content, such as audio or video, are not supported by older browsers or text-only browsers. Frames are also not universally supported by browsers and other user agents. Screen readers can struggle with continually updating dynamic content, such as scrolling news tickers. They may also fail to react to frame updates in the same way that they would to a page transition or refresh, which may cause problems. Users who have slow connections may disable browser features required to process and display dynamic content in order to speed up download times.

Directions and Techniques

Use the LINK element to direct users to alternative formats

The LINK element may also be used to designate alternative documents. Browsers should load the alternative page automatically based on the user's browser type and preferences. See the WAI recommended techniques for the Link element and alternative documents

Use scripts to automatically detect different browsers and present appropriate versions of web pages

A "browser detect" is a script which can detect the type of browser used by a visitor to a site. If a browser detect is used in combination with alternative versions, it is possible to present the user with a version of the page which works well in their browser. Note that it is not possible to detect if the user is using a screen reader because they are not browsers.

Use server side scripts to generate alternative pages on demand

Server side scripts, such as Java servlets, or PHP can be used to create alternative presentations of a page if the user requests one through their browser. The benefit of providing alternative pages in this way is that there is no requirement to maintain different "versions" of a website which reduces the maintenance effort and ensures that up to date content is delivered to the user, regardless of the version they select.

Provide a clear link to alternative version(s) at the top of each page

Providing the link at the top of the page means that the user does not have to wade through inaccessible content to view the alternative version. You should also provide a link to allow the user to navigate back to the original version.

Consider using user profiles for frequently visited pages

If the site contains information or services which a user is likely to use on an ongoing basis, consider providing them with the option to save a profile, which would save their preferences for the version of pages they need. This will save them the trouble of navigating to an alternate version each time.

Write scripts that transform gracefully

A script is said to transform gracefully if the information provided by the script is made available to the user, even if their browser or user agent does not support scripts. The presentation may vary and may not be as elegant as it would be if the users browser supported scripts but the information or functionality should be available. See the WAI recommended techniques for graceful transformation of scripts

If you use frames, provide a way to navigate to a non-frames version

You should write HTML which allows users of browsers which do not support frames to navigate to a version of your site which does not use frames. See the WAI recommended techniques for writing for browsers that do not support frames

Provide an offline equivalent

If it is absolutely impossible to deliver an accessible page, provide an offline service, delivered by trained personnel. Provide contact details such as email, telephone number, postal address and information on getting to the location if this is needed. This way information or services can be delivered over the phone, by correspondence, or in person. Because people often access the web at times outside normal office hours or from other time zones, you should consider offering this service on a 24 hour basis.

How you could check for this:

Test with different browsers and user agents

Testing with the widest variety of browsers and user agents, such as screen readers, Braille devices, etc. will show if an alternative presentation is required. If you provide alternative versions of content, test these to ensure that they are accessible. If you do not have direct access to this technology, get someone who knows how to evaluate the site to do so with these user agents.

- View WAI checkpoint 6.5

2.5 Use style sheets to control layout and presentation

WAI Checkpoint 3.3

Full WAI text: "Use style sheets to control layout and presentation."

Style sheets are used to define the presentation aspects of a web page, such as the fonts, sizes and colours used for text, headings and hyperlinks and the positioning of elements on the page. As far as possible, these should be used in place of hard coding element properties in the HTML.

Rationale

Using style sheets separates structure and presentation which brings several benefits, including improved accessibility, manageability, and portability.

Structure relates to the logical organisation of content. For example, an online form for a mortgage application might be broken up into logical sections such as personal information, employment details, house details, and so on. This logical structure will be the same for all users, but can be presented in many different ways, depending on the users' different needs and preferences. For example, in a detailed multiple-column graphical presentation making use of subtle colour cues, a single column using large text in high-contrast colours or as synthesized speech.

Accessibility is improved because users can choose between different styles and may even override the defined style sheets with their own. These could include larger font sizes or different colour schemes to improve legibility. Separating presentation and structure facilitates device independence, making it is easier to tailor the presentation to different browsers or user agents. Using style sheets also reduces the file size of web pages and speeds up download time, which is helpful for user who may be working with a slow connection.Style sheets help management and maintenance by allowing rapid changes to the visual appearance of a website. With style sheets, if there is a requirement to alter the presentation of a site, it can be done once, at the style sheet level, rather than on each separate page at the element level.

Directions and Techniques

Separate structure and presentation at the design stage

Design the structure of documents or web pages before thinking about how they will be presented to the user. Read the WAI guidance on separating structure and presentation

Use the accessibility features of Cascading Style Sheets (CSS)

Cascading Style Sheets provide many accessibility features. Refer to http://www.w3.org/TR/CSS-access for detailed technical explanations and examples of CSS accessibility features.

Use text and style sheets to control presentation, rather than relying on images

Layout, positioning, layering, and alignment can be done through style sheets. Using text instead of images makes the information on a web page available to a greater number of users (with speech synthesizers, Braille displays, graphical displays, etc.). If the presentation of the text is controlled with style sheets, the designer can still control the visual appearance using style sheet techniques such as floats and absolute positioning.

See the WAI recommended techniques for using text instead of images, CSS layout, positioning, layering and alignment and CSS text formatting and positioning.

Use the proper HTML elements to mark up emphasis

Use the EM and STRONG elements to indicate structural emphasis. This may then be rendered in a variety of ways (font style changes, speech inflection changes, etc.) by browsers, screen readers and other user agents. These elements should be used in favour of the B and I elements. See the WAI recommended techniques for marking up text emphasis

Refer to the WAI recommended techniques for this guideline

See the WAI recommended techniques for using style sheets to control layout and presentation

How you could check for this:

Test with the W3C CSS validator

Available from http://jigsaw.w3.org/css-validator/

- View WAI Checkpoint 3.3

2.6 Use relative rather than absolute units

WAI Checkpoint 3.4

Full WAI text: "Use relative rather than absolute units in mark-up language attribute values and style sheet property values."

Mark-up languages are languages like HTML which are used to define web pages. The HTML mark-up for elements such as text, headings and hyperlinks may specify presentation attributes such as the fonts, sizes and colours to be used. Style sheets can also be used to specify the presentation attributes of elements.

These attributes may be specified in either absolute or relative units. Absolute units are fixed values, such as a 12 point font size or an 800 pixel column width. Relative units define size in measurements like ems (a unit of width relative to a font size), or percentages of the total width of the browser window.

Whether controlled by mark-up or style sheets, sizes should be defined in relative units rather than absolute units.

Screen grab of web page showing some fixed and some resizable elements

Use HTML text and ensure that it is resizable
Browsers allow users to resize text that is specified in relative values. In this example the user cannot increase the size of the main navigation because tab graphics are used instead of HTML text. The sub navigation is scaleable because resizable HTML text is used.

Rationale

Designing for fixed sizes, such as for one "optimum" browser window size may look like a good idea on paper, as you may feel that you are controlling the presentation of the interface but in reality, it is a wasted effort. If an interface is designed with one "fixed" browser window size in mind, at best, it will not work well or will be completely unusable if the user does not work with that size window, as key features will disappear off the edge of the screen.

This affects users with smaller monitors, or users who like to enlarge the text size. If the width of the page is designed to display well in a fixed browser window size and the user enlarges the text, it could become too large to display on screen.

If the font size is fixed, the user can't scale it up to make it easy to read. They might want to do this if they were viewing content on a small screen, such as a mobile device or laptop, or if they have poor eyesight.Also, you will incur additional costs every time you decide to make your service available on another access device or platform, due to the effort required to "fit" the interface design in the new window size.Relative sizing not only means that the web site can be used on a wider variety of access devices, with the minimum design effort but you will also provide users with the flexibility to scale key elements to a size that suits their needs.

Directions and Techniques

Refer to the WAI recommended techniques for this guideline

See the WAI recommended techniques for using relative units of measurement

How you could check for this:

Try to change the size of text in the browser window

If you cannot re-size the text in the browser window by using the controls provided in the browser menu, this means that the font size has been defined with absolute sizes.

Test the site on various browser window sizes and monitor sizes

If you cannot see all of the content without scrolling horizontally, this means that the width of the window, or the tables on the page have been defined with absolute sizes. Note that images are an exception to this. Images cannot be re-scaled so they will not flow into a smaller window size in the same way that text will.

- View WAI Checkpoint 3.4

2.7 Use header elements to convey structure

WAI checkpoint 3.5

Full WAI text: "Use header elements to convey document structure and use them according to specification."

Headers are things like titles, section headings and row and column headings in tables, which are used to communicate the structure of the information on a web page. Headers should only be used to convey information structure, in accordance with the rules for use set out in the definition of the mark-up language. They should not be used to create presentation effects such as different sized text.

Rationale

Many people navigate or skim through documents by reading the headings to get a feel for the structure and an overview of the content and scope of a document.

HTML allows you to specify a hierarchy of heading levels by using different header tags - H1, H2, H3, etc. The tag not only defines the hierarchical order of a heading, it also affects visual presentation, so that an H1 heading looks bigger and bolder than an H2 heading. Using the header tags to make non-heading text bigger and bolder can confuse users by making content which is not a header look like one. This makes it very difficult to gain an understanding of the structure of a document or page.Also, some screen readers will read content assigned as a header in a different tone of voice to other content on the page, providing users with important clues about document structure. Misusing heading attributes will therefore misinform and confuse screen reader users.

Directions and Techniques

Order Heading elements correctly

Heading elements should always follow a logical hierarchical order. See the WAI recommended techniques for using header elements

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 3.5

2.8 Break up large blocks of information where appropriate

WAI checkpoint 12.3

Full WAI text: "Divide large blocks of information into more manageable groups where natural and appropriate."

Where possible, break the elements of the page into easy-to-comprehend logical chunks such as sections and sub-sections.

Rationale

People are generally uncomfortable with reading large tracts of text on screen and tend to skim through content by scanning headings, subheadings, lists, etc. This is easier to do if the content has been broken down in to easily digestible chunks.

More complex elements, such as forms or other interactive features, are easier to comprehend and navigate if they are broken into logical sections. For example, an online form might be broken up into logical sections such as personal information, employment details, and so on.Breaking content into small chunks helps everyone, including users who are in a hurry and need to find information quickly, such as call centre staff, users with reading difficulties, non-native speakers and users of screen readers. Grouping form elements, such as form fields and selection lists using correct HTML is very important for providing screen reader users with important contextual information which helps them to navigate through forms.Breaking complex forms into groups with correct HTML also makes error recovery a lot easier for users of screen readers as it simplifies the task of navigating back through a form to correct mistakes.It is important that groups of information are divided logically. Randomly created groups of elements will confuse users.

Directions and Techniques

Use section headings (H1 to H6) to create structured documents and break up long stretches of text

Section headings improve navigation through content and comprehension of content. See paragraph 1.2.1 "Section headings" in the WAI recommended techniques for grouping content items

Break up lines of text into paragraphs with the P element

Use the "P" element to define paragraphs in HTML.

Group related links

A navigation bar at the top of a web page is an example of grouping related links. Another example is a site map containing lists of links organised under site section headings. See paragraph 1.2.1 "Section headings" in the WAI recommended techniques for grouping links

Use UL, OL, and DL tags to nest list elements correctly

See the WAI recommended techniques for nesting lists

Use tables for tabular data and describe the table with CAPTION

Provide a caption for tables, using the CAPTION element. A table caption provides a short description of the table's contents, usually in one to three sentences. It could be considered as being similar to the title of a page. The "Caption" tag must be inserted immediately after the "Table" tag. You can specify only one caption per table. See the WAI recommended techniques for using tables for tabular data.

Group table rows and columns with THEAD, TBODY, TFOOT, and COLGROUP

These elements facilitate grouping of rows and columns in a table. This element is only valid inside the "Table" tag. It facilitates navigation and understanding by screen reader users and makes visually scanning, perceiving and printing information easier. See the WAI recommended techniques for grouping table rows and columns

Group form controls, elements and menu options into logical groups

HTML tags are available for grouping form elements and other interactive elements into logical groups. The resulting groupings are not always displayed in a standard browser, but they help ensure compatibility with assistive technologies. See the WAI recommended techniques for grouping form elements.

Use OPTGROUP to organize long lists of menu options into smaller groups

The OPTGROUP element can be used to group SELECT items (defined by OPTION) into a hierarchy. See the WAI recommended techniques for grouping menu options

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 12.3

2.9 Ensure that information laid out using tables make sense when linearised, or provide an alternative equivalent

WAI checkpoint 5.3

Full WAI text: "If Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearised version)."

A table is an HTML element which can be used to present information in tabular format or to control the visual presentation of a web page. If a table used to control the visual presentation of a web page is linearised, the content of the table data cells is displayed in one long column. The order in which the content is displayed in the linearised version is determined by the order in which the table cells are defined in the underlying HTML.

Ideally, the contents of the table would make sense when it is linearised but if not, you should provide the user with a choice to view the contents of the table in another format (i.e. paragraphs or blocks of text that are not displayed in a table).

Rationale

Tables were originally developed as an HTML feature, specifically for presenting tabular data and were never intended for controlling presentation. However, the data cells in a table can hold many different types of information, including text, numbers or images. Designers often use tables to control page layout. For example, to present text in a newspaper-like column layout, to display navigation elements on the left of the page with content in the middle or to position images inside blocks of text.

This creates a problem for users of screen readers or older technology. Older screen readers and text only browsers can't cope with information laid out in columns. If two columns of text are laid out side-by-side, a sighted person will read the left hand column from top to bottom before moving on to the next column. An older screen reader or text only browser will read from left to right, starting with the first sentence on the left hand column, then running over into the first sentence on the right column. This continues all the way down the page. The end result is that sentence fragments are combined into meaningless gibberish.

To avoid this problem, some users linearise tables on a web page - either through controls in their screen reader or web browser or by using a text only browser which can linearise tables.

The order in which the content is displayed in the linearised version is determined by the order in which the table cells are defined in the underlying HTML of the web page. This could be different to the order in which the tables are visually presented.

Consider reading a newspaper, where the headlines for all of the articles on a page are displayed at the top left of the page. The articles are then displayed one after the other in a long column and there is nothing to associate the headlines with their corresponding articles. There is also no easy way to tell when one article ends and another begins. This is what it is like to read a table which does not make sense when linearised.

Directions and Techniques

Separate structure and presentation

Design the structure of documents or web pages before thinking about how they will be presented to the user. Consider how the page will be read by a screen reader or with linearised tables. See WAI recommended techniques for separating structure and presentation

Use style sheets for layout wherever possible

Style sheets are not widely supported by web browsers at present but they should be used as support is increasing and style sheet positioning can be linearised in a way that makes sense. See WAI recommended techniques for using style sheets for layout

Provide an alternative page with a linearised version which makes sense

If you provide an alternative page with a linearised version of information which would otherwise be held in a table, ensure that the link is easily available, that the link title is meaningful and that the information contained in the linearised version is the same as in the non-linearised version.

How you could check for this:

Read tables in a linear browser

A text only browser, such as Lynx will show you how the page renders when the table is linearised. Opera is a web browser which allows you to linearise tables and this can also be used. Read the content of the table to see if it makes sense when linearised.

Test the table with a screen reader

Some screen readers don't cope well with tables and it is best to read the content of the table with one of these to see how the content reads when the table is linearised.

- View WAI checkpoint 5.3

2.10 Do not use structural mark-up to format information laid out using tables

WAI checkpoint 5.4

Full WAI text: "If a table is used for layout, do not use any structural mark-up for the purpose of visual formatting."

A table is an HTML element which can be used to present information in tabular format or to control the visual presentation of a web page. Do not define information contained in table cells as structural elements purely to achieve a visual effect if the table is used to control the layout a page.

Defining the text content of a table cell as a column heading so it displays as bold text is an example of misusing structural mark-up to achieve a visual effect.

Rationale

People who can visually scan a page that is laid out with tables can determine the structure of information by visually identifying and comparing structural elements - row and column headers, headings and subheadings. However, people who use a text-only browser or who can't see the page rely on an accurate description of structural elements to gain an understanding of it's structure.

If content items are incorrectly identified as structural elements in the underlying HTML, the page structure will not make sense when it is presented by a text only browser or screen reader.

Directions and Techniques

Separate structure and presentation

Design the structure of documents or web pages before thinking about how they will be presented to the user. Consider how the page will be read by a screen reader or with tables linearised. Refer to WAI Recommended Techniques for separating structure and presentation

How you could check for this:

Read tables in a text-only browser

A text only browser, such as Lynx will show you how the page renders when the table is linearised. Opera is a web browser which allows you to linearise tables and this can also be used. Read the content of the table to see if it makes sense when linearised.

Test the table with a screen reader

Some screen readers don't cope well with tables and it is best to read the content of the table with one of these to see how the content reads when the table is linearised.

- View WAI checkpoint 5.4

2.11 Describe the purpose of frames and how they relate to each other if it is not obvious by their titles alone

WAI checkpoint 12.2

Full WAI text: "Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone."

Frames allow the designer to break a web page into different pieces, each containing a different HTML file. Frames are often used to break the page into two sections - one containing information which does not change through the site and the other containing more dynamic information. A typical example is where the main navigation for a site is presented in a frame on the left side of the page, while content is presented in another frame on the right.

In this case, the navigation links are held in one HTML file on the left of the page while the content is held in another HTML file, the contents of which depend on the link selected from the left frame. Clicking a link in the frame on the left essentially causes a new page to open in the right hand frame.

Each frame should have a title, even though this is not displayed visually. If the titles of frames used to present a web page do not clearly explain the structural order or relationship between them and the nature of their contents, this information should be provided elsewhere.

Rationale

Users of older browsers or screen readers have difficulty in navigating web pages that use frames. They can't read all of the frames in a page at once and are therefore can't envisage the page structure.

When these users open a page with frames, they are presented with a list of the frames that make up the page. The list shows the frame titles. The user must then navigate each frame individually, a frustrating task if the frame titles are confusing. If that happens, the user is forced to open each frame individually, review the content and then try to figure out how it relates to the other frames on the page.For example, they may see a frame titled "nav". This is not very informative. If this frame's title said "links to the main site sections" it would be more useful.

Directions and Techniques

Describe frame relationships in the underlying HTML

Frame relationships and the nature of the contents of frames can be described in the underlying HTML which means that this information will be displayed in browsers which don't support frames. See WAI recommended techniques for describing frame relationships

How you could check for this:

Test the page with a browser with no support for frames

Open the page with a browser like Lynx, which will not display frames. This will show you how the page is presented when frames are not supported. If you see a list of frame titles and the purpose and relationship between these is not clear, consider adding a description.

- View WAI checkpoint 12.2

2.12 Clearly identify the target of each link

WAI checkpoint 13.1

Full WAI text: "Clearly identify the target of each link."

Provide clear, upfront information about the consequences of following a link, including its destination and any associated effects. The information that should be given includes the following:

  • The destination of the link
  • If following the link takes the user away from the current website
  • If following the link opens a new browser window
  • If following the link activates a feature which could tie up the browser for a while, such as a file download
  • If following the link submits information to a database

Rationale

Clear link titles are essential for users to decide whether they want to follow a link and to understand what happens when they do. It is particularly important for people who are not overly familiar with computers, the web, or your service.

Clear link titles are helpful for screen reader users, who will often review the list of links on a page before investing the time to read through the content in detail. This is the equivalent of visually scanning a page to get an overview of what it contains and what options are available. Because the list of link titles are read out of context, it's important to provide link titles that do not require the user to read the surrounding information. For example, "click here" and "more" mean nothing when read out of context.

Information about side-effects such as opening new browser windows can be essential to users who are easily confused or who cannot see the new window opening.Information about downloads is also essential, so that the user can decide whether they can afford the time and cost required for the download and whether they downloaded file is of a type they can read and which best suits their needs. It is very frustrating to download a document, only to find that it is not compatible with your system or software.

Directions and Techniques

Write clear and meaningful link titles which make sense when read out of context

See the WAI recommended techniques for link text

Avoid using the same title for two or more links that point to different places

Doing this is highly confusing. If two or more links refer to different targets but share the same link text, distinguish the links by specifying a different value for the "title" attribute of each A element. See the WAI recommended techniques for link text

Include warnings about pop-ups or new windows in link titles

Include a warning such as "(opens in a new window)" as part of any link title which activates a pop-up window. Including the warning as part of the hyperlink makes the link title more meaningful when read out of context, e.g. it will be read by screen reader users when they call up a list of links on the page.

Indicate file sizes and file types in links which activate downloads

Provide users with details of the file size and the document type in the link title. For example, "Report PDF (153K)". If possible, it is also useful to provide estimates of the download times for various types of connections alongside the download links. For example, "56K modem - 3 minutes".

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 13.1

2.13 Provide information about pages and sites in metadata

WAI checkpoint 13.2

Full WAI text: "Provide metadata to add semantic information to pages and sites."

Metadata is information that describes web sites, web pages and their contents. You should provide it to facilitate understanding of content.

Rationale

Good quality metadata improves usability of search facilities by providing useful and accurate keywords and descriptions of content and media types. The descriptions and summaries of page contents displayed in search results are often drawn from metadata which is inserted in web pages.

Metadata can also provide important contextual information to help users understand and navigate through content. Examples of metadata include descriptions of the contents and structural organisation of complex tables or long lists.

Without metadata, the information on your site is more difficult to share with users and other computers through data exchange facilities. It is difficult to archive and retrieve content if standard metadata schemes are not followed.

Directions and Techniques

Provide contextual clues in HTML lists using CSS techniques

Using UL and OL for lists, combined with CSS can provide contextual clues in lists. This helps users navigate through longer, more complex lists.

Insert metadata in web pages

Refer to this over view of metadata elements which can be included in the HTML of the web page.

Refer to the Inter departmental Recommended Guidelines for Public Sector Organisations

The Inter Departmental Recommended Guidelines for Public Sector Organisations describes recommendations on metadata standards for Irish public sector organisations. This document is relevant for anyone developing a website for Irish public sector organisations.

Check the HTML for META tags

If metadata has been included in the web page, it will not be visible. You have to check the HTML code to see it. To do this, open a web page on your browser, then select the option to "View Source" or "View Source Code". This will open the HTML code in a new window. You don't have to understand HTML to see if Meta tags are included. If they are present, they will be near the top of the source code, in the first few lines.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 13.2

2.14 Provide information about the general layout of a site

WAI checkpoint 13.3

Full WAI text: "Provide information about the general layout of a site (e.g., a site map or table of contents)."

Provide an overview of the site structure that summarises the contents and organisation of the site.

Rationale

An overview of the site structure and content makes navigation easier. For example, site map or table of contents makes navigating to key sections of the site easier than browsing through pages. It is sometimes assumed that users build "mental maps" of site structures in their heads by browsing through sections. This is not the case. Most people do not want to invest time figuring out how your site is structured. At best, they will remember no more than a handful of the pages they visited and the relationship between those pages.

A table of contents or site map can help people who have become confused or disoriented, to review the contents and continue navigating.

Directions and Techniques

Include a site map or table of contents

The site map should provide an overview of the key sections of the site and some indication of the content or functionality contained in those sections.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 13.3

2.15 Use navigation mechanisms consistently

WAI checkpoint 13.4

Full WAI text: "Use navigation mechanisms in a consistent manner."

Navigation mechanisms show the user where they can go in a site and their current position within the site structure. Examples include links, navigation bars, page or list numbers, site searching tools, advertising, headers and page titles. Navigation mechanisms should be presented in an orderly, uniform fashion, throughout a site.

Rationale

Providing consistent navigation devices and structures is important for all users. Inconsistently presented navigation mechanisms quickly disorient users and lead to mistakes, confusion and frustration.

Consistency makes your site more predictable, making it easier for users to navigate quickly to the information they want. It also helps users to skip unwanted chunks of navigation or content, which makes task completion or information retrieval more efficient.

Ensuring that the following characteristics of navigation mechanisms are more or less uniform throughout a site, or a series of related sites creates consistency:

  • Visual presentation - navigation elements look similar from page to page
  • Order - navigation elements are presented in a consistent sequence
  • Language - terminology is consistent
  • Behaviour - links and navigation controls always do the same thing when activated

Users who are not familiar with using computers or the web, users with learning difficulties or those in a hurry all benefit from consistent navigation mechanisms.

Maintenance is facilitated by consistency, as it is easier to implement changes and updates on a site that is built around a consistent framework.

Directions and Techniques

There are no specific techniques recommended for this guideline.

How you could check for this:

Compare different pages in the site

When you open each page, compare the positioning and presentation of the navigation elements. Compare the language and naming system for links and sections. Compare the behaviour of the navigation mechanisms.

If the site is part of a suite of sites, compare the entire suite

If users are likely to use more than one site in the suite, which could be several related sites from an organisation or a thematic collection of sites, then you should check for consistency across the suite.

- View WAI checkpoint 13.4

2.16 Associate labels explicitly with their controls

WAI checkpoint 12.4

Full WAI text: "Associate labels explicitly with their controls."

Examples of controls include text entry fields and checkboxes.

"Labels" are the names of form control elements, e.g. "first name" could be the label for a form element which could be a text entry field. In this case, the field name could be visually presented immediately above or to the left of the field. Associating the label with the form control by positioning the two as near as possible is called implicit labelling.

The relationship between the labels and control elements should be defined in the underlying HTML.

Rationale

It is good practice to position labels so the visual relationship with corresponding form controls is clear.

However, if the relationship between labels and form controls is not explicitly defined in the underlying HTML, older browsers or assistive technologies may fail to accurately present the form.

Directions and Techniques

Label forms with the correct HTML

See WAI recommended techniques for explicitly defining relationships between controls and labels See also this example from IBM which shows how to label different types of form control

How you could check for this:

Test with a screen reader or audio browser

Testing with a screen reader or audio browser will show you how the form labels and controls are associated.

Test the reading order of the form with The WAVE

The WAVE is an automated tester which reads the underlying HTML of a web page and returns a report that shows the reading order. This is a very useful tool for testing pages with forms as it shows how implicitly labelled forms would be read by a screen reader or text only browser. Go to the WAVE home page

- View WAI checkpoint 12.4

2.17 Properly position the labels of form controls

WAI checkpoint 10.2

Full WAI text: "Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned."

A user agent is a piece of software for accessing Web content. User agents could be desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software.

Examples of form control elements include text entry fields and checkboxes. Labels should be associated with form elements by locating them in close proximity to each other.

"Labels" are the names of form control elements, e.g. "first name" could be the label for a form element which could be a text entry field. In this case, the field name could be visually presented immediately above or to the left of the field. Associating the label with the form control by positioning the two as near as possible is called implicit labelling.

Rationale

It is good practice to position labels so the visual relationship with corresponding form controls is clear. However, some assistive technologies, like screen readers, can only read left to right and unless form labels are positioned carefully, they will fail to read the form in a meaningful way.

Directions and Techniques

Lay out forms carefully

Put labels beside form controls, not above them. Screen readers read left to right. Doing this will make it easy to read the form and make sense of it with a screen reader

How you could check for this:

Test with a screen reader or audio browser

Testing with a screen reader or audio browser will show you how the form labels and controls are associated.

Test the reading order of the form with The WAVE

The WAVE is an automated tester which reads the underlying HTML of a web page and returns a report that shows the reading order. This is a very useful tool for testing pages with forms as it shows how implicitly labelled forms would be read by a screen reader or text only browser. Go to the WAVE homepage

- View WAI checkpoint 10.2

2.18 Ensure that user interfaces are device-independent

WAI checkpoint 9.2

Full WAI text: "Ensure that any element that has its own interface can be operated in a device-independent manner."

Examples of elements that have their own interfaces include interactive features or web based applications such as tax calculators or games written in Java or Macromedia Flash. These elements are embedded in a web page and have their own controls, input and output mechanisms.

Ensure that it is possible to interact with controls, provide inputs and perceive outputs of such elements using the widest range of input devices (including the mouse, keyboard, microphone, Braille devices, head wands or other pointing devices) or output devices (including display monitors, loudspeakers, headphones or Braille devices).

Rationale

Interfaces which do not provide flexibility in the type of device used to interact with them are inherently inaccessible. A laptop user may choose to work without a mouse. If this were the case and interactive features on a site required "drag and drop" interactivity as the only means of interaction, the site would be unusable. Similarly, a site delivered through a kiosk or public access terminal with only a touch screen interface would be unusable.

Developing device independent interfaces facilitates porting the site to the widest range of computing devices, including mobile handsets, PCs, and Interactive Voice Response systems (IVRs).

Screen reader users rely entirely on keyboard input and audio output for interacting with websites. Failing to provide support for audio output or the keyboard as an input device will make the site unusable for them. Other users may use voice input for hands-free operation in a busy office, or if they have dexterity limitations.

Directions and Techniques

Separate structure and presentation

Design the structure of documents or web pages before thinking about how they will be presented to the user. Refer to WAI recommended techniques for separating structure and presentation

If you use Java to create applets, consult the Java Look and Feel Guidelines from Sun

Java has inherent accessibility features. Ensure that you have provided for input device independence using them. Refer to Sun's guidelines on accessibility features provided in Java for details on using them.

How you could check for this:

Disconnect the mouse and try to navigate with the keyboard

Assuming that you know how interact with a website using keyboard only navigation, this simple test will very quickly show you if it is possible to navigate or interact with the site using an input device other than the mouse. Be especially sure to test interactive features like forms, drop-down menus, pop-out menus, etc.

- View WAI checkpoint 9.2

2.19 Use logical event handlers in scripts

WAI checkpoint 9.3

Full WAI text: "For scripts, specify logical event handlers rather than device-dependent event handlers."

Scripts are pieces of functionality written in languages other than HTML, to provide dynamic or interactive behaviour ranging from simple visual effects to mini applications.

Some examples are enhanced functionality like pop-up menus coded in DHTML, form input validation routines written in JavaScript and interactive applications such as tax calculators or games written in Java or Macromedia Flash.

An event handler is a script that is invoked when a certain event occurs (e.g, the mouse moves, a key is pressed, the document is loaded, etc.).

You must ensure that event handlers, which activate interactive features delivered through scripts and applets, can be activated and controlled using the widest range of input devices, including the mouse, keyboard, microphone, Braille devices, head wands or other pointing devices.

Some event handlers produce effects which are purely visual but others are used to complete critical tasks such as submitting the contents of a form, completing a calculation or sending a message. Event handlers critical to completing a task should always be input device independent.

Rationale

Interfaces, which do not provide flexibility in the type of device which the user must rely on to input information or to receive outputs, are inherently inaccessible. A laptop user may choose to work without a mouse and favour the keyboard instead. If this were the case and interactive features on a site required "drag and drop" interactivity as the only means of interaction, the site would be unusable. Similarly, a site delivered through a kiosk or public access terminal with only a touch screen interface would be unusable if you can't see the screen.

This issue is not confined to inputting information. It is also important to provide device independent output. A screen reader user may be able to open a DHTML menu but if they receive no feedback on the names of the links they are selecting, the menu is unusable. Similarly, they may be able to open a Javascript tax calculator and input data but if the output is not compatible with a speech synthesiser, then it is not device-independent.

Developing interfaces which provide input device independence facilitates porting the site to the widest range of computing devices, including mobile handsets, PCs, and Interactive Voice Response systems (IVRs).

Screen reader users rely entirely on the keyboard for interacting with websites. Failing to support the keyboard as an input device will make the site unusable to them. Other users may use voice input for hands-free operation in a busy office, or if they have dexterity limitations.

Directions and Techniques

Separate structure and presentation

Design the structure of documents or web pages before thinking about how they will be presented to the user. Refer to WAI recommended techniques for separating structure and presentation

If you must use device-dependent attributes, provide redundant input mechanisms

In HTML 4.01, application-level event attributes are "onfocus", "onblur" (the opposite of "onfocus"), and "onselect". Note that these attributes are designed to be device-independent, but are implemented as keyboard specific events in current browsers. Otherwise, if you must use device-dependent attributes, provide redundant input mechanisms (i.e., specify two handlers for the same element):

  • Use "onmousedown" with "onkeydown"
  • Use "onmouseup" with "onkeyup"
  • Use "onclick" with "onkeypress"

Note that there is no keyboard equivalent to double-clicking ("ondblclick") in HTML 4.01.

If you use Java to create applets, consult the Java Look and Feel Guidelines from Sun

Java has inherent accessibility features. Ensure that you have provided for input device independence using them. Refer to Sun's guidelines on accessibility features provided in Java for details on using them.

Refer to IBM Accessibility Centre for more information on scripts

The IBM Accessibility Centre provides more information on scripts and accessibility

How you could check for this:

Disconnect the mouse and try to navigate with the keyboard

Assuming that you know how interact with a website using keyboard only navigation, this simple test will very quickly show you if it is possible to navigate or interact with the site using an input device other than the mouse. Be especially sure to test interactive features like forms, drop-down menus, pop-out menus, etc.

Test with a variety of input devices

Testing with a range of devices, including keyboard, mouse, special pointing devices which are supported by the user agent, will show if the event handlers can be used with the breadth of input devices supported by a user agent.

- View WAI checkpoint 9.3

2.20 Use input device-independent event handlers in scripts and applets

WAI checkpoint 6.4

Full WAI text: "For scripts and applets, ensure that event handlers are input device-independent."

Scripts and applets are types of programmatic objects. These are pieces of functionality written in languages other than HTML, to provide dynamic or interactive behaviour ranging from simple visual effects to mini applications.

Some examples are enhanced functionality like pop-up menus coded in DHTML, form input validation routines written in JavaScript and interactive applications such as tax calculators or games written in Java or Macromedia Flash.

An event handler is a script that is invoked when a certain event occurs (e.g, the mouse moves, a key is pressed, the document is loaded, etc.). You must ensure that event handlers which activate interactive features delivered through scripts and applets, can be activated and controlled using the widest range of input devices, including the mouse, keyboard, microphone, Braille devices, head wands or other pointing devices.

Some event handlers produce effects which are purely visual but others are used to complete critical tasks such as submitting the contents of a form, completing a calculation or sending a message. Event handlers critical to completing a user task should always be input device independent.

Rationale

Interfaces which do not provide flexibility in the type of device which the user relies on to input information are inherently inaccessible. A laptop user may choose to work without a mouse. If this were the case and interactive features on the site relied on "drag and drop" interactivity as the only means of interaction, the site would be unusable. If this site were delivered through a kiosk or public access terminal with a touch screen interface, it would be unusable.

Screen reader users rely entirely on the keyboard for interacting with websites. Failing to support the keyboard as an input device will make the site unusable to them. Other users may use voice input for hands-free operation in a busy office, or if they have dexterity limitations.Input device independence facilitates porting the site to the widest range of computing devices, including mobile handsets, PCs, and Interactive Voice Response systems (IVRs).

Directions and Techniques

Separate structure and presentation

Design the structure of documents or web pages before thinking about how they will be presented to the user. Consider how the page will be read by a screen reader or with tables linearised.Refer to WAI recommended techniques for separating structure and presentation

Use application-level event triggers rather than user interaction-level triggers

In HTML 4.01, application-level event attributes are "onfocus", "onblur" (the opposite of "onfocus"), and "onselect". Note that these attributes are designed to be device-independent, but are implemented as keyboard specific events in current browsers. Otherwise, if you must use device-dependent attributes, provide redundant input mechanisms (i.e., specify two handlers for the same element):

  • Use "onmousedown" with "onkeydown"
  • Use "onmouseup" with "onkeyup"
  • Use "onclick" with "onkeypress"

Note that there is no keyboard equivalent to double-clicking ("ondblclick") in HTML 4.01.

Do not write event handlers that rely on mouse coordinates

This is bad practice because it relies on the use of a mouse and a highly visual style of interaction to invoke an event handler. Event handlers that rely on mouse coordinates don't support keyboard input.

If you use Java to create applets, consult the Java Look and Feel Guidelines from Sun

Java has inherent accessibility features. Ensure that you have provided for input device independence using them. Refer to Sun's guidelines on accessibility features provided in Java for details on using them.

How you could check for this:

Disconnect the mouse and try to navigate with the keyboard

Assuming that you know how interact with a website using keyboard only navigation, this simple test will very quickly show you if it is possible to navigate or interact with the site using an input device other than the mouse. Be especially sure to test interactive features like forms, drop-down menus, pop-out menus, etc.

- View WAI checkpoint 6.4

2.21 Ensure that scripts and applets are accessible

WAI checkpoint 8.1

Full WAI text: "Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2]."

Scripts and applets are types of programmatic objects. These are pieces of functionality written in languages other than HTML, to provide dynamic or interactive behaviour ranging from simple visual effects to mini applications.

Some examples are enhanced functionality like pop-up menus coded in DHTML, form input validation routines written in JavaScript and interactive applications such as tax calculators or games written in Java or Macromedia Flash.

Programmatic elements should either be inherently accessible or should include features that ensure they are usable with assistive technologies.

Assistive technologies enable users to provide inputs and perceive outputs where they can't do so using technologies like the mouse, keyboard or monitor screen. For example, blind users may use a screen reader, which is a program that interprets the text contents of the screen and outputs this either to a speech synthesiser or a Braille display. Users with low vision may use a screen magnifier program to enlarge a selected portion of the screen. People with motor impairments may require a special keyboard or a pointing device controlled by a joystick or by head movements.

Rationale

Ideally programmatic elements should be directly accessible so the widest audience can use them without having to resort to assistive technologies. This is not always possible, as many browsers or operating systems do not include adequate accessibility features. In this case, accessibility features which are provided in programming technologies and supported by assistive technologies should be included in programmatic elements.

Direct accessibility is desirable in situations where the user wants to access a service or information delivered through HTML pages but can't use their assistive devices or technologies because it is not practical or feasible. For example, using a screen reader to interact with a kiosk in a public place. This would be impossible because screen readers are typically installed on the user's PC and configured it to suit their needs.

Directions and Techniques

Write directly accessible applets

See WAI recommended techniques for writing directly accessible applets

If you use Java to create applets, consult the Java Look and Feel Guidelines from Sun Microsystems

Java has inherent accessibility features. Ensure that you have provided for input device independence using them. Refer to Sun's guidelines on accessibility features provided in Java for details on using them.

How you could check for this:

Test programmatic elements with assistive technologies

Testing with assistive technologies such as screen readers, screen magnifiers, special pointing devices will show whether they are directly accessible or compatible with assistive technologies. You should consider testing with real users and if you do this, be sure to follow a structured user test methodology.

Test programmatic elements with keyboard only navigation

Try to operate it using only the keyboard. If some functionality cannot be reached or properly controlled, then it is not accessible.

- View WAI checkpoint 8.1

2.22 When an appropriate markup language exists, use markup rather than images to convey information

WAI Checkpoint 3.1

Full WAI text: "When an appropriate markup language exists, use markup rather than images to convey information."

Mark-up refers to commands or symbols used to describe a document's logical structure or to indicate how it should look when it is printed or displayed. For example, HTML heading styles (h1, h2, etc.) are used to mark up section headings on a web page. MathML can be used to mark-up mathematic symbols and equations. It is possible to achieve the same visual effect by using images instead of markup, but this should be avoided.

Rationale

Sometimes designers use images to display text or symbols in a visually appealing format. This causes problems because images can't be described as part of an overall document structure which means that a lot of important contextual information is lost.

Users cannot re-size text that is displayed as images in their browser, which makes it difficult to read for people with poor eyesight who prefer larger sizes. Screen readers and Braille displays can translate mark-up into speech or Braille, making content and structure more intelligible to blind users.

Directions and Techniques

Use correct mark-up and style sheets to display symbols

Use mark-up to display symbols, such as currency symbols, mathematical or scientific notation. See the WAI recommended techniques for using markup rather than images. This includes an example of mark-up and style sheets used to display mathematical information using MathML.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI Checkpoint 3.1

2.23 Create documents that validate to published formal grammars

WAI Checkpoint 3.2

Full WAI text: "Create documents that validate to published formal grammars."

An HTML document's mark-up must follow the rules which are set out in a formal set of mark-up declarations which are contained in a published formal grammar or Document Type Definition (DTD).

Rationale

Documents that are created using published formal grammars will be supported by more browsers and assistive technologies.

Many accessibility features of assistive technology, accessible web technology, and web browsers rely on published formal grammars. Failing to work to a formal published grammar may make a web page directly inaccessible or inaccessible to assistive technologies like screen readers, Braille devices, etc.Writing code which validates to formal grammars also facilitates indexing tools, search engines, programs that extract tables to databases, navigation tools that use header elements and automatic text translation software.

Directions and Techniques

Include a document type declaration referring to a published DTD

Use the DOCTYPE statement as the first line of your HTML file for the particular grammar (e.g. the strict HTML 4.0 DTD) that the code adheres to.

Refer to the WAI recommended techniques for this guideline

See the WAI recommended techniques for creating documents that validate

How you could check for this:

Test with the W3C HTML validator

The W3C HTML validator can check HTML to ensure that it validates to formal grammars. The W3C also provide a comprehensive list of the formal grammars which it uses. Some authoring tools also include validators. If you use an authoring tool, you should ensure that the validator is up to date.

- View WAI Checkpoint 3.2

2.24 Mark up lists and list items using the proper HTML tags

WAI checkpoint 3.6

Full WAI text: "Mark up lists and list items properly."

HTML allows you to create different types of lists for different purposes. Each of these lists has display properties that are appropriate to its purpose. For example, in an ordered list the items are numbered, whilst an unordered list uses bullets.

Elements which belong in lists should be marked up as lists, rather than having the bullets of numbers added to the elements themselves. Elements which do not belong in lists should not be marked up as lists for the sake of visual presentation. For example, you should not assign an element to a list as a means of displaying it with a number or bullet.

Lists with more than one logical level can also be marked up correctly to create a compound number system such as 1.1, 1.2, 2.1, etc.

Rationale

Screen reader users will refer to the numbers in an ordered list for navigation and context. If the numbers do not relate to a clear structural hierarchy, users will be easily confused.

Directions and Techniques

Use a compound number system for complex numbered lists

Complex lists, such as those numbered 1.1, 1.2, 2.1, and so on, can be created using the WAI recommended techniques for HTML list mark-up and creating ordered lists with CSS

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 3.6

2.25 Use quotation mark-up for quotations, but not for formatting

WAI checkpoint 3.7

Full WAI text: "Mark up quotations. Do not use quotation mark-up for formatting effects such as indentation."

HTML allows you to mark-up quotations from external sources and publications. These will then be displayed in an appropriate way.

Text which is a quotation should be marked up as a quotation, rather than having quote marks and indentation specified as attributes. Text which is not a quotation should not be marked up as a quotation for the sake of visual presentation. For example, you should not mark-up text as a quotation as a means of displaying it within quotation marks.

Rationale

Correct use of the quotation mark-up can break the page into chunks of content which helps users to read content more easily on-screen.

Some screen readers will read content assigned as a quotation in a different tone of voice, providing users with important clues about document structure. Misusing quotation attributes will therefore confuse screen reader users.

Directions and Techniques

Use "Q" and "BLOCKQUOTE" elements for inline and block quotations, respectively.

The "Q" tag should be used within a paragraph to quote a direct source. The "BLOCKQUOTE" tag should be used for longer quotes, which are "blocked" or indented from the page margins. See the WAI recommended techniques for Marking up quotations

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 3.7

2.26 Where possible, use appropriate W3C technologies of the latest supported versions

WAI checkpoint 11.1

Full WAI text: "Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported."

Build web pages with technologies which are endorsed by the World Wide Web Consortium (W3C) and are capable of delivering the functionality you require to implement a user requirement. Work with the most recent specification of whatever W3C technology you choose for a particular development.

Rationale

The World Wide Web Consortium (W3C) is an independent, international body that creates Internet and programming language standards, including the WAI guidelines, of which this is one. Its recommendations and standards are highly regarded.

W3C technologies include standardised versions of HTML, XML, style sheets, multimedia and many other technologies. They are non-proprietary, which means that they are more likely to be usable across a wide variety of browsers and user agents.

If non-W3C technologies are used, the user may be required to download or use plug-ins or stand-alone applications which are not always accessible. Also, W3C technologies are continually reviewed for accessibility. By using a W3C technology, you are more likely to embed accessibility in your website.The latest versions of W3C technologies include many features which will improve accessibility, though not necessarily immediately. These features are built into W3C technologies on the assumption that newer browsers and other user agents will be able to take advantage of them. Using these features will not adversely affect the performance of a site in older browsers and user agents, provided they are properly implemented. Including such features in current web development projects will help ensure that the site is "future-proofed".

Directions and Techniques

Refer to the WAI references for information on W3C technologies

The WAI references for information on W3C technologies is included in the Web Content Accessibility Guidelines View a full list of W3C technologies

Refer to WAI-UA-SUPPORT

This documents known support by user agents (including assistive technologies) of some accessibility features. View the WAI-UA-SUPPORT

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 11.1

2.27 Avoid deprecated features of W3C technologies

WAI checkpoint 11.2

Full WAI text: "Avoid deprecated features of W3C technologies."

A "deprecated" feature is one which the W3C wants to remove from the official standard for a given technology but which has not yet become officially obsolete or removed. Even though they are part of the official standard, the W3C discourages the use of deprecated features. For example, the "font" tag in HTML is an example of a deprecated feature in HTML 4.0.

Rationale

The World Wide Web Consortium (W3C) is an independent, international body that creates Internet and programming language standards. Its recommendations and standards are highly regarded.

W3C technologies are continually reviewed for accessibility so that the latest versions may have discarded some features which have been found to hinder accessibility. By using a current W3C technology, you are more likely to embed accessibility in your website.

Directions and Techniques

Consult the W3C list of HTML elements and attributes

The index of HTML elements and attributes lists all elements in HTML 4.0. Deprecated elements are indicated with an asterisk.

Write Cascading Style Sheets (CSS) which support user override of styles

Users can override CSS with their own style sheets, which may be configured to suit their needs. This is an important feature of CSS and should be provided. See the WAI recommended techniques for user override of styles.

Avoid using deprecated features for presenting fonts

See the WAI recommended techniques for specifying font styles.

How you could check for this:

Test with the W3C HTML validator

The W3C HTML validator can check HTML to ensure that it validates to formal grammars. The W3C also provide a comprehensive list of the formal grammars which it uses. Some authoring tools also include validators. If you use an authoring tool, you should ensure that the validator is up to date and validates for deprecated features.

- View WAI checkpoint 11.2

2.28 Do not periodically auto-refresh pages

WAI checkpoint 7.4

Full WAI text: "Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages."

User agents are software which people use to access Web content. These include graphical browsers, text-only browsers, voice browsers, mobile phones, multimedia players, plug-ins and assistive technologies such as screen readers, screen magnifiers and voice recognition software.

It is possible to create pages which automatically reload in the user's browser every so often, as long as the browser window is open. This should be avoided at present, since not all user agents allow the user to disable auto-refresh.

Rationale

Automatically reloading a new page, or the same page with new content, can be very confusing and frustrating for users who may not be overly familiar with computers and using the web. Many people find auto-refreshing pages highly confusing because they take control of navigation away from users, who can quickly become disoriented and fail to grasp the structure of a site.

Users read at different rates. It is highly disruptive and unsettling if the page refreshes before the user has had a chance to either determine the content of the page, or before they finish reading it. This can make pages or content unusable for users who have limited reading ability or difficulty concentrating because of noise, stress or a learning disorder. Auto refresh also causes problems for users of screen readers, which generally cannot cope with auto-refresh and may fail to show any content at all.

Directions and Techniques

Provide a mechanism or control for disabling auto-refresh

If you create auto-refreshing pages using Java applets or other techniques, you should provide an obvious control which allows the user to control the rate of refresh or to disable page refreshing altogether.

Avoid using the META element for auto-refresh

See the WAI description of why META should not be used to redirect or auto-refresh pages

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 7.4

2.29 Do not use mark-up to redirect pages automatically

WAI checkpoint 7.5

Full WAI text: "Until user agents provide the ability to stop auto-redirect, do not use mark-up to redirect pages automatically. Instead, configure the server to perform redirects."

User agents are software which people use to access Web content. These include graphical browsers, text-only browsers, voice browsers, mobile phones, multimedia players, plug-ins and assistive technologies such as screen readers, screen magnifiers and voice recognition software.

It is possible to create pages which automatically send or "direct" the user to a new web page, as if they were following a link. Auto-redirect links are often "invisible" in the sense that they are not presented as a choice on the page but are embedded in the HTML. This should be avoided at present, since not all user agents allow the user to disable auto-redirect.

Rationale

Automatically redirecting to a new page can be very confusing and frustrating for users who may not be overly familiar with computers and using the web. Many people find auto-direct pages highly confusing because they take control of navigation away from users, who can quickly become disoriented and fail to grasp the structure of a site. Automatically directing to another page erodes a user's trust in a site as it takes away their control over the navigation and interaction.

Users read at different rates. It is highly disruptive and unsettling if the page refreshes before the user has had a chance to either determine the content of the page, or before they finish reading it. This can make pages or content unusable for people who have limited reading ability or difficulty concentrating because of noise, stress or a learning disorder. Auto redirect also causes problems for users of screen readers, which generally cannot cope with automatic re-directs and may fail to show any content at all.

Directions and Techniques

Configure the server to use the appropriate HTTP status code (301)

Using HTTP headers is preferable because it reduces Internet traffic and download times, it may be applied to non-HTML documents, and may be used by agents who requested only a HEAD request (e.g. link checkers). Also, status codes of the 30x type provide information such as "moved permanently" or "moved temporarily" that cannot be given with META refresh.

Avoid using the META element for automatic redirects

See the WAI description of why META should not be used to redirect or auto-refresh pages

Replace the page that would be redirected with a static page containing a normal link to the new page

Provide a static page with a link and, ideally, an explanation that the user will be directed to another page. This is good practice because it provides upfront information about the new page. Users will be less likely to become disoriented if they know what to expect. If you provide a link, ensure that the link title is meaningful.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 7.5

2.30 Do not generate pop-ups or other windows and do not change the current window without informing the user

WAI checkpoint 10.1

Full WAI text: "Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user."

User agents are software which people use to access Web content. These include graphical browsers, text-only browsers, voice browsers, mobile phones, multimedia players, plug-ins and assistive technologies such as screen readers, screen magnifiers and voice recognition software.

It is possible to create pages which cause new windows to open automatically. This is called "spawning" and the new windows are called "pop-ups" because they tend to pop open on the desktop, on top of the original window. Pop-ups usually contain advertising content but they are sometimes used to present error messages. Each time a pop-up appears, the focus on the user's desktop goes to that window.

Pop-up windows should be avoided at present, since not all user agents allow the user to disable pop-ups. If pop-ups are used, you should inform the user.

Rationale

Pop-ups can be very confusing and frustrating for users who may not be overly familiar with computers or the web. Many people find them annoying because they take control of the desktop away from the user, who can quickly become disoriented. Pop-ups can erode a user's trust in a site as it takes away their control over the navigation and interaction.

Pop-ups cause problems for screen reader users because they take the focus without warning. This means that the screen reader begins reading the content of the new window, usually without warning the user that a new window has opened. If the new window contains content from another site, the user can become very disoriented and confused.

Directions and Techniques

Avoid using pop-ups to present error messages

Pop-ups should not be used as a way to present error messages on HTML forms because the content of the pop-up is not provided within the context of the form itself. This means that the user has to read the content of the pop-up, then find the relevant position on the form before they can fix the error.

Include warnings about pop-ups in link titles

Including a message like "(opens in a new window)" as part of link titles which activate pop-ups. Including the warning as part of the hyperlink makes the link title more meaningful when read out of context, e.g. it will be read by screen reader users when they call up a list of links on the page.

Refer to the WAI recommended techniques for this guideline

See the WAI recommended techniques for avoiding pop-ups.

How you could check for this:

Open the page and see if new windows appear

New windows can appear over or under the original window. You should also test forms to ensure that pop up windows are not used for error messaging by submitting deliberately incorrect information on forms.

- View WAI checkpoint 10.1

Priority 3

Following priority 3 will improve access for one or more groups.

3.1 Ensure that text and background have sufficient contrast for people with colour deficient vision

WAI Checkpoint 2.2

Full WAI text: "Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. [Priority 2 for images, Priority 3 for text]."

The difference in contrast between the colour of text and the colour of the background should be sufficient for users to be able to read the text, including users who have impaired colour vision or who use a black and white screen.

Rationale

Not everyone can easily distinguish between close colour combinations and tones. Some users find it difficult to read text when the text and it's background are similar in tone, even if the colours are different. This particularly affects older users or those who have some form of colour blindness.

Users may also find it hard to distinguish between colours if they use a poor quality or monochrome screen.

Colour has three attributes which determine how people perceive it: hue, lightness and saturation. Hue is the basic perceived colour, essentially the name of the colour, e.g. a scarf could be "red". Lightness is tonal quality, e.g. the scarf could be red but described as "dark red". Saturation is the amount of colour, e.g. the scarf is "very red". As colours become less saturated, they move toward being either black or white.

Colour schemes which achieve clear differentiation in all three attributes provide the greatest contrast. Peoples' perception of the contrast of colour is bound up in their ability to perceive any or all of the three attributes, and this varies greatly. You should never assume that if you can clearly perceive a colour combination as being a good contrast then others will too.

Examples of high and low contrast between text and background colours

High and low contrast text
Ensure that foreground and background colour combinations provide sufficient contrast when viewed by a person with colour deficits or when viewed on a black and white screen.

Directions and Techniques

Understand how colour contrast is perceived

For more information on how colour choice affects perceived contrast, see Lighthouse.

How you could check for this:

View the page on a monochrome monitor

This will give show how the page would look without colour and you can determine if colour differential is essential for understanding the information.

Print the page on a black and white printer

This will provide some indication of how the page would look without colour. However, this is not a foolproof test. Most browsers are configured so they don't print background colours which could be displayed behind the main body of text on the page.

Use Vischeck

Vischeck is a free piece of software which can emulate how a page would appear to a user who is colour blind. Go to Vischeck

- View WAI Checkpoint 2.2

3.2 Provide text links to emulate client-side image maps

WAI Checkpoint 1.5

Full WAI text: "If you use images and image maps: until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map."

Image maps are images which are made up of many parts, each of which is a separate graphical button or link. The parts with the link are the "active regions".

With client-side image maps, the user clicks on a point on the image map and the coordinates of the point they click on are collected and processed by their browser. The browser then sends a request to the server where the site is hosted, to activate a command.

A user agent is a piece of software for accessing Web content. User agents could be desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software.

Redundant text links correspond to the links contained in the active regions of the image map but are presented in text format, in addition to the links in the image map itself.

Not all user agents are capable of automatically providing users with a list of redundant text links. Until such time as they do so, you must provide a redundant set of links.

Rationale

Because image maps tend to rely on the "point and click" style of interaction, they can be inherently unusable for anyone not using a mouse. The user may not work with a mouse if they are working with a laptop, a mobile device, a screen reader or if they have limited manual dexterity and can't control the mouse accurately. Providing redundant text links allows these users to access the controls or pages behind the image map.

Directions and Techniques

Use the "A" element to provide redundant text links

See WAI recommended techniques on providing redundant text links with the "A" element

How you could check for this:

Test the site with a text only browser

A text only browser cannot recognise images and will present the text only. Pages with server-side image maps will be unusable unless redundant text links are provided.

- View WAI Checkpoint 1.5

3.3 Expand the first occurrence of any abbreviation or acronym

WAI Checkpoint 4.2

Full WAI text: "Specify the expansion of each abbreviation or acronym in a document where it first occurs."

An acronym is a word formed from the initials of a multi-word name, while an abbreviation is a shortened or truncated version of a word or a phrase. Identify and provide the full meaning of abbreviations or acronyms when they first appear in a page or document.

For example, if you use a word like "NATO", you would need to explain that this is an acronym meaning "North Atlantic Treaty Organisation".

If you use a word like "E.U." or "EU", you would need to explain that this is an abbreviation meaning "European Union".

Rationale

Abbreviations may be indecipherable when machine-spoken or output as Braille.
Correct mark-up of abbreviations or acronyms makes reading easier for users of screen readers, audio browsers and Braille devices.

In addition, providing expansions of acronyms and abbreviations directly in the text of content - as you would in a document created in a word processor - improves readability for users from other countries, those who have never encountered the abbreviation before and users with reading difficulties.Note: in the near future, browsers will let you choose to have abbreviations and acronyms expanded automatically but until this is generally supported, it is best to continue to specify the expansion.

Directions and Techniques

Define acronyms and abbreviations using the correct HTML

See the WAI recommended techniques for marking up abbreviations and acronyms with ABBR and ACRONYM and TITLE to indicate the expansion.

Provide the expansion, at the first occurrence, in the content

Provide expansions of acronyms and abbreviations directly in the content, as you would in a document created in a word processor.

How you could check for this:

Get a technical writer to review the document

A technical writer or a trained proof reader should be able to find and define the meaning of acronyms and abbreviations in documents. Ideally this should happen before they are published on the web.

- View WAI Checkpoint 4.2

3.4 Identify the primary language of the document text

WAI Checkpoint 4.3

Full WAI text: "Identify the primary natural language of a document."

Natural language refers to spoken, written or signed languages, such as English, Irish, Irish Sign Language and Braille. The predominant natural language of a web page should be identified in the underlying HTML of the page.

Rationale

Speech synthesisers and Braille devices need to know the natural language so they can pronounce the words on the page correctly. Failing to identify the natural language could cause these devices to mispronounce the information making it impossible to understand.

Identifying the natural language also facilitates automated translators - software or machines - which can read the content of the page and translate it into another language.

Directions and Techniques

Identify the primary natural language in the underlying HTML

See WAI recommended techniques for identifying natural language

Use the correct codes for identifying natural languages

Refer to the ISO list of codes for natural languages

How you could check for this:

Test the page with a screen reader or audio browser

Before you run this test, you will need to ensure that the screen reader or audio browser supports the natural language you are testing. If it does, you can test for that language. If not, this test is not reliable. Also ensure that any required dictionaries are installed in the software you use for this test.

- View WAI Checkpoint 4.3

3.5 Place distinguishing information at the beginning of headings, paragraphs, lists, etc.

WAI Checkpoint 13.8

Full WAI text: "Place distinguishing information at the beginning of headings, paragraphs, lists, etc."

Provide concise up-front information.

Rationale

Users come to web sites to find specific information or functionality and have little time to waste. Content should be presented in such a way that makes it easy to scan.

Visually reading online content is tiring and uncomfortable for most users but for users with low vision, it can be painful.

Users prefer to scan through headings, titles, paragraphs and lists to quickly find what they want. Scanning is made easier when the purpose and content of each chunk of content on the page is communicated at the beginning of each chunk.

Directions and Techniques

State the topic of the sentence or paragraph at the beginning of the sentence or paragraph

This will help users who visually skim or who use screen readers. Screen reader users skim by jumping from heading to heading, or paragraph to paragraph, listening to just enough to determine whether the current chunk of information (heading, paragraph, link, etc.) interests them.

Use meaningful, concise headings and link descriptions

Link titles should make sense when read out of context or as part of a series of links (Some users browse by jumping from link to link and listening only to link text.) Meaningful headings help users scan a page quickly for information.

Involve a technical writer and work to a style guide

If you publish a lot of content, you should involve a technical writer or a trained editor and set up an editorial process, involving a style guide to ensure that content is always well written.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI Checkpoint 13.8

3.6 Supplement text with graphic or auditory presentations where they will facilitate comprehension

WAI Checkpoint 14.2

Full WAI text: "Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page."

Provide explanatory images or audio content where this helps users to understand the meaning of the main body of text content on a web page.

Rationale

Some concepts can be explained with words only but others are easier to explain with combinations of words, images and sounds. For example, a piece of music could best be explained with descriptive text (words), musical notation (images) and an audio example (sounds).

Users with cognitive or reading difficulties, non-native users or users who communicate primarily in sign language may struggle with information presented entirely through text. A wide variety of techniques can be used to provide supporting information, including animations, icons, graphs, video, recorded speech, synthesised speech, sound effects or sound alerts.Note: It is important to provide equivalents for any supporting information you provide to ensure that it is available to the widest possible audience. For example, the information communicated through a graph should also be available in text format as well.

Directions and Techniques

There are no specific techniques recommended for this guideline.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI Checkpoint 14.2

3.7 Provide summaries for tables

WAI checkpoint 5.5

Full WAI text: "Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page."

Provide a brief overview of the purpose and structure of information presented in tabular format.

Rationale

Providing a summary of the purpose and structure of the contents of a data table helps users who may be browsing with non-visual browsers, such as screen readers or text only devices. Summary is an HTML attribute which is not displayed in a standard browser. In other words, for a screen reader user, the summary would be read aloud, before the contents of the table cells. A summary tells the user what information is presented in the table and names the table headings.

Providing this contextual information simplifies navigating and understanding the tables, especially if they are complex. A typical summary would sound like this "This table charts the annual percentage growth in internet usage in Ireland under the headings, 1999, 2000, 2001."

Note that tables used for layout do not require summaries.

Directions and Techniques

Include the "Summary" attribute in the HTML used to create data tables.

Summaries are included in HTML, with the <TABLE> tag as follows; <TABLE SUMMARY="insert your summary here.">

How you could check for this:

Open the table with a screen reader

If the summary is not read aloud, it is possible that a summary was not included. Note that summaries are not really required for very simple tables, e.g. a table with only one row of data, organised in a very small number of columns may not require a summary as it would be simple enough to navigate and comprehend.

Check the HTML used to create the table

View the source code for the table. The SUMMARY attribute should be visible as part of the HTML used to create the table.

- View WAI checkpoint 5.5

3.8 Provide abbreviations for table header labels

WAI checkpoint 5.6

Full WAI text: "Provide abbreviations for header labels."

A header is the name of a column or row in a data table. If long header titles are used, provide shorter versions. This is done by inserting an abbreviation attribute into the underlying HTML that identifies the header element.

Rationale

Users of screen readers or audio browsers find listening to the content of long and complex tables with long header names cumbersome and repetitive. Providing meaningful abbreviations reduces repetition and improves reading efficiency. For example, a header on a column which reads "Percentage growth of internet usage" could be abbreviated to simply, "growth".

Directions and Techniques

Use the ABBR attribute when describing table headers

See WAI recommended techniques for using the ABBR atribute to describe table headers

How you could check for this:

View the source code to see if attributes are provided

Open the HTML code which presents the table and check to see if the abbreviations are included through the correct use of the ABBR element. Note that an abbreviation is only necessary for long names and may not be helpful if the table is short and easy to understand without an abbreviation.

- View WAI checkpoint 5.6

3.9 Identify groups of related links and provide a way to bypass them

WAI checkpoint 13.6

Full WAI text: "Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group."

Organise lists of links according to the logical structure of the site or web page. Assign headings and subheadings for each list of links and until user agents (web browsers, screen readers, etc.) are capable of automatically detecting and skipping over long lists of unwanted links, provide a way for the user to do this themselves.

A user agent is a piece of software for accessing Web content. User agents could be desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software.

Rationale

A navigation bar is often the first thing presented on a page. Screen reader users have to listen to this over and over again, for every page until they get to the unique content. Providing a way to skip over repetitive links to allow users to start reading at the beginning of the main body of the page improves efficiency.

Some screen readers provide an option to skip links that are the same on subsequent pages, However, the functioning of this option is at best hit and miss, so it is better to provide for it proactively.

Skip links are useful for people who navigate with the keyboard, including laptop users and users with limited dexterity who can't use a mouse. Providing skip links saves them the hassle of having to use the tab key to negotiate long lists of links.

Grouping links into logical structural groups helps all users by providing content overviews of key sections of the site or on a longer web page.

Directions and Techniques

Consider whether to visually show or hide skip links

If you do decide to make the skip link option visible, place it in the most unobtrusive place possible. For example, consider putting the skip links on the top right rather than the top left, as this is easier to ignore for people who don't want or need to use it.

If you decide to hide the skip links, you can use a single pixel "invisible" gif with the anchor tag and suitable alt text to provide a "hidden" link that will be identified by a screen reader but not to a sighted user. This is easy to implement and has little impact on the page.

Provide a style sheet that allows users to hide the set of navigation links

Taking advantage of style sheets will allow you to present users with the option to show or hide skip links or groups of navigation links, depending on their needs. See WAI recommended techniques for hiding links with stylesheets

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI checkpoint 13.6

3.10 Provide a linear alternative for parallel, word-wrapped columns of text

WAI checkpoint 10.3

Full WAI text: "Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns."

Content which is presented as side-by-side text, laid out in parallel columns like a newspaper page should also be presented without the columns so users of older web browsers or assistive technologies, which can't cope with columns, can read the content. This "no columns" or linearised version could be provided on the same page as the version with columns, or it could be presented on another page.

A user agent is a piece of software for accessing Web content. User agents could be desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software.In the context of information technologies, assistive technologies help people to use computers, websites, public access terminals where otherwise, they couldn't. Examples of assistive technologies are screen readers, hearing aids, special keyboards, pointing devices or other technical solutions which allow the user to provide an input and or receive an output from a computer.Not all user agents or assistive technologies automatically allow users to linearise columns. Until such time as they do, you must provide the linear alternative.

Rationale

Some assisitive technologies, especially older ones, don't recognise columns and can't present the information in a way that makes sense to the user. They will often read left to right, top to bottom down the page and will fail entirely to separate the columns. Imagine listening to someone read a newspaper page in this way; the output is a confusing mish-mash of sentence fragments which do not in make any sense to the listener. All context and meaning is lost.

Assistive technologies tend to be expensive and learning to use them can also demand a considerable effort of the user which discourages users from upgrading them on a routine basis, as opposed to standard browsers which are often free of charge and comparatively easy to use. This is one reason why it is important to develop sites with older technologies in mind.

Directions and Techniques

Ensure that the content of alternative, linearised versions is up to date

If you provide an alternative version of a web page, or part of a web page, make sure that the content is equally up to date on both versions. This is not a problem with database driven sites but will take some effort on "static" HTML sites.

Provide a meaningful link title to the alternative version and provide it high on the page

Ensure that the link title which takes the user to the alternative version is easy to get to and that it makes sense when read out of context.

"Linearised" does not mean "text only"

Linearised versions of web pages are often presented as "text only" versions. This happens when developers mistakenly assume that only screen reader users avail of the alternative version. Linearised versions may be used by people who prefer the layout either because they like it or because it suits their browser. Just because a browser can't cope with tables does not automatically imply that it can't also cope with images. Supporting images are helpful and should be included wherever possible.

How you could check for this:

Determine if a linearised version is required

Run a sheet of paper down the page and read the page line by line, left to right. Ignore columns - including navigation links which could be presented in a column at the left or right of the page. If the content does not make sense when read this way, a linearised version is required.

- View WAI checkpoint 10.3

3.11 Create a logical tab order through links, form controls, and objects

WAI Checkpoint 9.4

Full WAI text: "Create a logical tab order through links, form controls, and objects."

When the "TAB" key is used to move the cursor, the cursor's movement should follow the structural order of the page elements so the user can select and activate them. It should be possible to use the "TAB" key to make the cursor jump between page elements like form fields, buttons and other controls, links, pop-out menus or more complex interactive features.

Rationale

Many users rely on the keyboard as their primary device for navigating and interacting with websites. Many laptop and notebook users, screen reader users and users with limited dexterity favour keyboard navigation. Internet kiosks don't always provide the user with a mouse.

If a user fills in an online form where the logical tabbing order is incorrectly defined, they could easily submit the form without filling in all the required fields because the cursor jumps to the "submit" button before they are finished.

Failing to provide a logical tab order is highly confusing and makes the task of navigating and using websites very difficult, especially for users of screen readers who may fail to notice that the cursor is not following the correct order.

Directions and Techniques

Specify a tabbing order among elements with the "tabindex" HTML attribute

This is the HTML tag required to specify the tabbing order. See WAI recommended techniques for specifying a logical tab order

How you could check for this:

Test the tabbing order with the keyboard

Open a web page and press the tab key. Each time you press the key you will see that the cursor moves and highlights a link, or a control element. Follow the progress of the cursor and ensure that it corresponds to the logical structure of the page. It is important to test forms as well as content pages.

- View WAI Checkpoint 9.4

3.12 Provide keyboard shortcuts to important links, form controls, and groups of form controls

WAI Checkpoint 9.5

Full WAI text: "Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls."

Keyboard shortcuts are combinations of keystrokes on the keyboard that can activate functionality or links. Keyboard shortcuts should be provided to links to key sections or to interact with key functional features of a site.

This also applies to links that are embedded in image maps. Image maps are images which are made up of many parts, each of which is a separate graphical button or link.

Rationale

Keyboard short cuts improve the efficiency of an interface for all people. They save time and effort for users who work in a busy environment and are also very helpful for screen reader users, who rely on the keyboard as their main input device.

"Short cut keys are very important. These are vital to navigate and you have to learn them off if you're blind. At first, this means a lot of effort and a lot of memory work but after a while once you start to get used to them, you can end up being faster than someone who has to look at the screen and move a mouse around." - blind user

Older people and users with arthritis or limited dexterity also find keyboard shortcuts very useful, as they are often easier to use than a mouse.

Directions and Techniques

Use the "Accesskey" HTML attribute to define shortcut keys

To create keyboard shortcuts, define them in the underlying HTML by binding them to a particular action, such as following a hyperlink or submitting a form. For WAI recommended techniques on creating keyboard shortcuts, see using accesskey to create keyboard shortcuts for links and creating keyboard shortcuts for form controls

Explain keyboard shortcuts where they are provided

Inform users that keyboard shortcuts are available, what the key combinations are and what they do when activated. Consider displaying the keyboard shortcut for a command or link, beside associated page element. For example the shortcut for the link to the home page could be displayed as follows: Home (Alt+1).

Alternatively, provide a list of all the shortcuts on a page, which the user could open in another browser window, as a reference. Inform the user that the link to the list will open a new window on their desktop.

Choose the combinations for keyboard shortcuts with care

Keyboard shortcuts created with the Accesskey attribute override application level shortcuts, i.e. "CTRL + P" would no longer activate the browser's print command, if that combination were assigned to activate a control on a web page. This can easily confuse users, so it is important to avoid using these mappings that are common to user agents.

Provide keyboard shortcuts but do not rely on them

The Accesskey feature is not widely supported by web browsers, so you should not rely on keyboard shortcuts as the only means of controlling the site functionality.

How you could check for this:

Compare the shortcut combinations to the described actions.

Make a list of the keyboard shortcuts provided on a website, then test each shortcut to ensure that it causes the action described in the list.

- View WAI Checkpoint 9.5

3.13 Separate adjacent links with non-link, printable characters surrounded by spaces

WAI Checkpoint 10.5

Full WAI text: "Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links."

A user agent is a piece of software for accessing Web content. User agents could be desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software.

Not all user agents can differentiate between hyperlinks that appear beside each other, unless they are separated by a text character which is not part of the link. Until such time as they can, text characters that are not part of a link should separate hyperlinks.

Rationale

Older user agents, especially screen readers, can't differentiate between hyperlinks when the links are listed side by side. Some designers try to overcome this by placing an "invisible" image between the links but this does not work reliably.

Consider this list representing 4 different of hyperlinks, displayed in a horizontal line: "Home About Us Contact Us Site Search". An older screen reader would read this as one hyperlink called "HomeAboutUsContactUsSiteSearch" and would try to read that title aloud. This would sound like nonsense, making navigation impossible.

Directions and Techniques

Insert a text character between lists of links

A text character such as the "|" character, a comma or the space " " character can be used to separate adjacent links.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI Checkpoint 10.5

3.14 Provide navigation bars

WAI Checkpoint 13.5

Full WAI text: "Provide navigation bars to highlight and give access to the navigation mechanism."

Present a consistently available list of links to key sections in the site.

Rationale

Providing a consistently available navigation bar makes navigating through the site easier by moving easily between key sections, without having to continually return to the home page.

Directions and Techniques

Display the navigation bar on every page of the site

Include the names of key sections - especially the home page so users can quickly and easily navigate back through the site if they are lost. Ensure that the navigation bar is located consistently within the page structure, so that users do not have to search for it and get confused as they navigate through the site.

Display a "breadcrumb trail" on every page and especially on multi-page forms

A breadcrumb trail is a navigation device that shows the user where they are in the site structure. For example, "You are here: Home, Web Accessibility, Guidelines, Guideline Number 3.7". To facilitate backward navigation, the following elements from this breadcrumb trail could be hyperlinks "Home, Web Accessibility, Guidelines".

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI Checkpoint 13.5

3.15 If search functions are provided, enable different types of searches for different skill levels and preferences

WAI Checkpoint 13.7

Full WAI text: "If search functions are provided, enable different types of searches for different skill levels and preferences."

A search function is something used to locate and retrieve information within a website. Provide users with the flexibility to search the site using a method which suits their needs.

Users may search by browsing (through content, headings, lists of links, site maps, indexes, tables of contents) or by using automated features that look up an index of keywords or the contents of a database.

Rationale

Users search websites in different ways and a well-designed search facility can greatly improve the efficiency of information retrieval on even the smallest web site.

All users make spelling mistakes from time to time. Providing search facilities which make allowances for spelling errors in automated search forms is very helpful to everyone and especially so for people who are not familiar with the language of the site, specialised terminology, or users with reading difficulties.Providing users with the option to search a site by browsing in different ways is also helpful. Some users prefer browsing over using key word searches because they may feel that the returns are more accurate, or because they may want a "fallback" when the keyword they envisage does not necessarily correspond with those used in the schema of the site.

Directions and Techniques

Make allowances for user spelling mistakes

Users with reading difficulties and users unfamiliar with the language of your site will have a difficult time finding what they need if the search requires perfect spelling. Search engines might include a spell check, offer "best guess" alternatives, query-by-example searches, similarity searches, etc.

Assign correct structural definitions to structural elements

Structural elements include things like headings and subheadings, links, lists, paragraphs, META content, page titles, etc. If these are correctly defined with HTML, searching will be improved because users and automated systems will be able to easily identify these elements.

Use meaningful titles for key structural elements

Using meaningful, descriptive titles for structural elements makes searching easier. If headings, page titles, etc. are meaningful users can quickly determine whether they are relevant or not when they search a site, whether this information is provided as part of a list of search returns or while browsing.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI Checkpoint 13.7

3.16 Provide information about documents comprising multiple pages

WAI Checkpoint 13.9

Full WAI text: "Provide information about document collections (i.e., documents comprising multiple pages)."

"Documents" is a definition that includes websites, reports, brochures, manuals, proposals, guidelines, etc., which have more than one page. A group of related documents is a document collection.

Provide an explanation of the relationship between documents in a document collection by including page numbers, chapter numbers, tables of contents, etc.

Rationale

This facilitates online or offline browsing and reading of documents. Users who connect to the web through a domestic connection do not like to read long documents online because of the cost of the connection. Users with reading difficulties may need more time to read through documents and they will also appreciate the cost savings introduced by downloading documents and reading them offline.

Users can navigate through document collections more efficiently and effectively if they understand how they are organised.

Directions and Techniques

Use the LINK element and link types

This HTML tag describes document navigation mechanisms and organisation. Some user agents may synthesize navigation tools or allow ordered printing of a set of documents based on such mark up. See WAI recommended techniques on using the LINK element

Create bundled document collections with a compression application

An application which compresses files can be used to make document file sizes smaller which will increase download speeds. Zip files are an example of compressed files. Ensure that whatever format you provide files in can be readily opened without the user having to download additional plug-ins or expensive software.

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI Checkpoint 13.9

3.17 Provide a means to skip over multi-line ASCII art

WAI checkpoint 13.10

Full WAI text: "Provide a means to skip over multi-line ASCII art."

ASCII art refers to text characters and symbols that are combined to create an image. The following is an ASCII image of a smiling face :) This is a very simple example but it is possible to create elaborate pictures that can fill the screen. Allow users to bypass ASCII art taking up more than one line on the screen.

Rationale

ASCII art is made up of real text characters. These are read aloud by audio browsers and screen readers and are basically rendered as gibberish because the screen reader will say each character. To save users from having to listen to this "verbal clutter", you should provide users with the option to skip over multi-line ASCII.

Directions and Techniques

There are no specific techniques recommended for this guideline.

How you could check for this:

Open the page and check for ASCII art

If there is ASCII art on the page, check to see if it takes more than one line on the screen. If it does, look for a link which allows users skip over the image. Note that this could be a hidden link, which would mean that you have to check the code.

- View WAI checkpoint 13.10

3.18 Create a style of presentation that is consistent across pages

WAI Checkpoint 14.3

Full WAI text: "Create a style of presentation that is consistent across pages."

Present content in a constant, uniform way across the entirety of a web site. Content includes information, instructions and error messages presented through text, visual or audio formats.

Text and audio content should have a uniform tone of voice, structure, terminology, etc. Visual content should appear coherent by sharing similar colour schemes, icons, proportions, etc.

Rationale

Consistency is very important for all users of a website. Inconsistently presented web sites disorient users and lead to mistakes, confusion and frustration.

Consistency makes your site more predictable and helps users to learn how it works, making it easier for them to navigate to the information they want, each time they visit a site. It also helps users to skip unwanted chunks of navigation or content, which makes task completion or information retrieval more efficient.

Ensuring that the following characteristics are more or less uniform throughout a site, or a series of related sites creates consistency:

  • Visual presentation - elements look similar from page to page
  • Order - elements are presented in a consistent sequence
  • Language - terminology is consistent
  • Behaviour - links and navigation controls always do the same thing when activated

Users who are not familiar with using computers or the web, users with learning difficulties or users in a hurry will all benefit from consistent navigation mechanisms.

Consistency also facilitates navigation, as it is easier to implement changes and updates on a site that is built around a consistent style.

Directions and Techniques

Use style sheet techniques to improve consistency

See WAI recommended techniques on using style sheets to improve consistency

Create and use a style guide

A style guide is a reference for people who add content to the site or who manage sites. It should set out the basic rules and guidelines for writing content, visual presentation and behaviour of controls and interactive features. Note that a style guide is only as good as the person who uses it. If there is no system in place for reviewing content against a style guide, you may as well not have one.

How you could check for this:

Compare different pages in the site

When you open each page, compare the positioning and presentation of the navigation elements. Compare the language and naming system for links and sections. Compare the behaviour of the navigation mechanisms.

If the site is part of a suite of sites, compare the entire suite

If users are likely to use more than one site in the suite, which could be several related sites from an organisation or a theme-based collection of sites, then you should check for consistency across the suite.

- View WAI Checkpoint 14.3

3.19 Include default text in form text boxes

WAI checkpoint 10.4

Full WAI text: "Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas."

A control is part of a form. There are different types of controls, including edit boxes and text areas, which are types of form fields that are used to input text information such as postal details, phone numbers, etc. These form fields are often displayed as empty fields but should really contain some helpful text to provide users with a prompt to help them understand the purpose of the form field. Drop-down menus and scrolling lists should include this information as the first option on the list. Radio buttons should have an option selected.A user agent is a piece of software for accessing Web content. User agents could be desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software.Not all user agents can cope with empty form fields and until such time as they do, you should include default characters.

Rationale

Some user agents will not recognise empty form controls and will pass over them. This disorientates users, making it impossible to fill out forms. A screen reader would probably receive an error message if they tried to submit the contents of such a form.

Mobile devices may also fail to cope with empty form fields.

Directions and Techniques

Use the correct HTML to put default place-holding characters in text areas

See WAI recommended techniques for assigning default characters in edit boxes and text areas. See CAST's reccomendations on coding edit boxes, text areas, drop selection lists and radio buttons.

How you could check for this:

Check forms for empty form fields

Open any page with a form and look for empty fields, unselected radio buttons and drop down menus with no default option.

- View WAI checkpoint 10.4

3.20 Provide information to enable users to receive documents according to their preferences

WAI Checkpoint 11.3

Full WAI text: "Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)" Allow users to select a presentation format which suits their needs by explaining the options available and allowing them to choose accordingly. This could involve choosing the language which content is delivered through, the media (text or images with text) or other options.

Rationale

Allowing users to choose between different interface options is good practice, as long as the range of options and their meaning is clearly explained up-front.

Users who want to download files such as documents, program executables or multimedia files will want to select versions compatible with their systems. Users are very reluctant to commit to downloading files, especially larger files, if they can't tell whether they will be able to open or use them.

Non-native users may want to select different language options, while users of older technology, text-only browsers or screen readers may prefer to use pages that are optimised for these user agents.

Directions and Techniques

Provide clearly available links to alternative presentations

Whenever alternatives are available provide clear links to the alternatives.

Configure the server to choose document preferences automatically

Browsers can send information about what representations they prefer when they contact the server to request a web page. For example, a browser could indicate that it would like to see information in Irish or English.

Consider using profiles to record user preferences

User preferences for document and page settings can be stored in profiles, so they are automatically served on repeat visits.

Indicate file sizes and file types in links which activate downloads

Providing users with details of the file size and document type in the link title makes it easier to ensure that they are downloading the file which best suits their needs. It is very frustrating to download a document, only to find that it is not compatible with your system or software.

Use the aural property attributes if you use aural style sheets

Aural style sheets specify the presentation of aural content. They can be overridden with user style sheets in the same way as Cascading Style Sheets so users can set the attributes of the aural output to suit their needs, provided they were specified in the original style sheet. See WAI recommended techniques for using aural properties

Use Cascading Style Sheets (CSS) to specify content presentation

CSS specify the presentation of content. They can be overridden with user style sheets. This means that users can set presentation attributes to suit their needs, provided they were specified in the original style sheet. See WAI recommended techniques on specifying content presentation with CSS

Use the CSS2 "media types" attributes

The CSS2 "media types" (used with @media rules) allow authors and users to design style sheets that will cause documents to render more appropriately on certain target devices. See WAI recommended techniques on using media types attributes

How you could check for this:

There are no specific test methods recommended for this guideline.

- View WAI Checkpoint 11.3