Note: We plan to continue adding and updating this document. All South African government departments are requested to address issues on accessibility as soon as it is possible. Any new developments should address all issues on accessibility.
These guidelines explain how to make web content accessible to people with disabilities. Adhering to them will also make web content more accessible to all users. Their needs will be met, no matter what device they use e.g.
- desktop browser
- voice browser
- mobile phone
- automobile-based personal computer
or whether they access content in
- noisy surroundings
- under- or over-illuminated rooms
- in a hands-free environment, etc.
Following these guidelines will also help people find information on the web more quickly. These guidelines do not discourage the use of such things as images and video but explain how to make multimedia content more accessible to a wide audience.
1. Introduction
Many users may operate devices in contexts very different to yours:
- They may not be able to see, hear, move, or may not be able to process some types of information easily or at all.
- They may have difficulty reading or comprehending text.
- They may not have or be able to use a keyboard or mouse.
- They may have a text-only screen, a small screen, or a slow Internet connection.
- They may not speak or understand fluently the language in which the document is written.
- They may be in a situation where their eyes, ears, or hands are busy or interfered with such as driving to work, or working in a loud environment, etc..
- They may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system to yours.
You must take into account these situations during page design. While there are several situations to consider, each accessible design choice generally benefits several disability groups at once and the web community as a whole.
2. Themes of Accessible Design
These guidelines address two general themes: ensuring graceful transformation, and making content understandable and navigable.
2.1 Ensuring Graceful Transformation
By following these guidelines, content developers can create pages that transform gracefully. Here are some keys to designing pages that transform gracefully:
- Separate structure from presentation.
- Provide text (including text equivalents). Text can be rendered in ways that are available to almost all browsing devices and accessible to almost all users.
- Create documents that work even if the user cannot see and/or hear. Provide information that serves the same purpose or function as audio or video in ways suited to alternate sensory channels as well. This does not mean creating a pre-recorded audio version of an entire site to make it accessible to users who are blind. Users who are blind can use screen reader technology to render all text information in a page.
- Create documents that do not rely on one type of hardware. Users who do not have a mouse or who use
- small screens
- low resolution screens
- black and white screens
- no screens, with only voice or text output
must be able to access pages.
The theme of graceful transformation is addressed primarily by guidelines 1 to 11.
2.2 Making Content Understandable and Navigable
You should make content understandable and navigable. This includes
- making the language clear and simple
- providing understandable mechanisms for navigating within and between pages.
Providing navigation tools and orientation information in pages will maximise accessibility and usability. Not all users can use visual clues such as image maps, proportional scroll bars, side-by-side frames, or graphics that guide sighted users of graphical desktop browsers. Users lose contextual information when they can only view a portion of a page, either because they access the page
- one word at a time (speech synthesis or Braille display)
- one section at a time (small display, or a magnified display).
Without orientation information, users may not be able to understand very large tables, lists, menus, etc.
The theme of making content understandable and navigable is addressed primarily in guidelines 12 to 14.
3. Web Content Accessibility Guidelines
This document only includes the checkpoints that the World Wide Web Consortium (W3C) recommends. Please refer to the W3C for the checkpoints that the W3C recommends should or may be implemented.
Guideline 1. Provide equivalent alternatives to auditory and visual content.
Provide content that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content.
Although some people cannot use images, movies, sounds, applets, etc. directly, they may still use pages that include equivalent information to the visual or auditory content. The equivalent information must serve the same purpose as the visual or auditory content. Thus, a text equivalent for an image of an upward arrow that links to a table of contents could be "Go to table of contents". In some cases, an equivalent should also describe the appearance of visual content (e.g. complex charts, billboards, or diagrams) or the sound of auditory content (e.g. for audio samples used in education).
Checkpoints:
For information on implementation please refer to the W3C.
1.1 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
- image map regions
- animations
- 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
- video.
For example, in HTML: Use "alt" for the IMG, INPUT, and APPLET elements, or provide a text equivalent in the content of the OBJECT and APPLET elements.
1.2 Provide redundant text links for each active region of a server-side image map.
1.3 Provide an auditory description of the important information of the visual track of a multimedia presentation.
1.4 For any time-based multimedia presentation (e.g. a movie or animation), synchronise equivalent alternatives (e.g. captions or auditory descriptions of the visual track) with the presentation.
Guideline 2. Don't rely on colour alone
Ensure that text and graphics are understandable when viewed without colour
If colour alone is used to convey information, the following will not receive the information:
- people who cannot differentiate between certain colours
- users with devices that have non-colour or non-visual displays.
When foreground and background colours are too close to the same hue, they may not provide sufficient contrast when viewed
- using monochrome displays or by people with different types of colour deficit.
Checkpoints:
2.1 Ensure that all information conveyed with colour is also available without colour, for example from context or mark-up.
Guideline 3. Use mark-up and style sheets and do so properly
Create ark-up documents with the proper structural elements. Control presentation with style sheets rather than with presentation elements and attributes.
Using mark-up improperly - not according to specification - hinders accessibility. Misusing mark-up for a presentation effect makes it difficult for users with specialised software to understand the organisation of the page or to navigate it. E.g. using a table for layout or a header to change the font size. Furthermore, using presentation mark-up rather than structural mark-up to convey structure (e.g. constructing what looks like a table of data with an HTML PRE element) makes it difficult to render a page intelligibly on other devices.
Checkpoints: W3C currently has no checkpoints on this guideline with the recommendation that it must be implemented. Refer to the W3C for checkpoints that the W3C recommends should or may be implemented.
Guideline 4. Clarify natural language usage
Use mark-up that facilitates pronunciation or interpretation of abbreviated or foreign text.
When content developers mark-up natural language changes in a document, speech synthesisers and Braille devices can automatically switch to the new language. This makes the document more accessible to multilingual users. Content developers should identify the predominant natural language of a document's content (through mark-up or HTTP headers). Content developers should also provide expansions of abbreviations and acronyms.
Checkpoints:
4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g. captions).
For example, in HTML use the "lang" attribute. In XML, use "xml:lang".
Guideline 5. Create tables that transform gracefully
Ensure that tables have necessary mark-up to be transformed by accessible browsers and other devices.
Use tables to mark up truly tabular information ("data tables"). Content developers should avoid using them to lay out pages ("layout tables"). Tables for any use also present special problems to users of screen readers.
Checkpoints:
5.1 For data tables, identify row and column headers. [W3C priority - must implement]
For example, in HTML, use TD to identify data cells and TH to identify headers.
5.2 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.
For example, in HTML use
- THEAD, TFOOT, and TBODY to group rows
- COL and COLGROUP to group columns
- "axis", "scope", and "headers" attributes, to describe more complex relationships among data.
Guideline 6. Ensure that pages featuring new technologies transform gracefully
Ensure that pages are accessible even when newer technologies are not supported or are turned off.
Content developers are encouraged to use new technologies that solve problems raised by existing technologies. However, they should know how to make their pages compatible with older browsers and people who choose to turn off features.
Checkpoints:
6.1 Organise 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.
When content is organised logically, it will be rendered in a meaningful way when style sheets are turned off or not supported.
6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes.
6.3 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
For example, ensure that links that trigger scripts work when scripts are turned off or not supported (e.g. do not use "javascript:" as the link target). If it is not possible to make the page usable without scripts:
- provide a text equivalent with the NOSCRIPT element
- use a server-side script instead of a client-side script
- provide an alternative accessible page.
Guideline 7. Ensure user control of time-sensitive content changes
Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped
Some people with cognitive or visual disabilities are unable to read moving text quickly enough or at all. Movement can also cause such a distraction that the rest of the page becomes unreadable for people with cognitive disabilities. Screen readers are unable to read moving text. People with physical disabilities might not be able to move quickly or accurately enough to interact with moving objects.
Checkpoints:
7.1 Avoid causing the screen to flicker. [W3C priority - must implement]
Note. People with photosensitive epilepsy can have seizures triggered by:
- flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second
- quick changes from dark to light (like strobe lights).
Guideline 8. Ensure direct accessibility of embedded user interfaces
Ensure that the user interface follows principles of such things as accessible design: device-independent access to functionality, keyboard operability, and self-voicing.
When an embedded object has its "own interface", the interface -- like the interface to the browser itself -- must be accessible. If the interface of the embedded object cannot be made accessible, an alternative accessible solution must be provided.
Checkpoint:
8.1 Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies
Guideline 9. Design for device-independence
Use features that enable activation of page elements via a variety of input devices
Device-independent access means that the user may interact with the device or document with a preferred input (or output) device such as:
- voice
- a mouse
- keyboard
- head wand
- or other means.
For example, if a form control can only be activated with a mouse or other pointing device, someone without sight who uses the page will not be able to use the form, because they use:
- voice input
- a keyboard
- or some other non-pointing input device.
Note. Providing text equivalents for image maps or images used as links makes it possible for users to interact with them without a pointing device.
Generally, pages that allow keyboard interaction are also accessible through speech input or a command line interface.
Checkpoints:
9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
Guideline 10. Use interim solutions
Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly
For example, older browsers do not allow users to navigate to empty edit boxes. Older screen readers read lists of consecutive links as one link. These active elements are therefore difficult or impossible to access. Also, changing the current window or popping up new windows can be very disorienting to users who cannot see that this has happened.
Checkpoints: W3C currently has no checkpoints on this guideline with the recommendation that it must be implemented. Refer to the W3C for checkpoints that the W3C recommends should or may be implemented.
Guideline 11. Use W3C technologies and guidelines
Use W3C technologies (according to specification) and follow accessibility guidelines. Provide an alternative version of the content that is accessible where
- it is not possible to use a W3C technology
- doing so results in material that does not transform gracefully, .
The current guidelines recommend W3C technologies (e.g. HTML, CSS, etc.) for several reasons:
- W3C technologies include "built-in" accessibility features.
- W3C specifications undergo early review to ensure that accessibility issues are considered during the design phase.
- W3C specifications are developed in an open, industry consensus process.
Many non-W3C formats (e.g., PDF, Shockwave, etc.) require viewing with either plug-ins or stand-alone applications. Often, these formats cannot be viewed or navigated with standard user agents (including assistive technologies). Avoiding non-W3C and non-standard features (proprietary elements, attributes, properties, and extensions) will tend to make pages more accessible to more people using a wider variety of hardware and software. When inaccessible technologies (proprietary or not) must be used, equivalent accessible pages must be provided.
Even when W3C technologies are used, they must be used in accordance with accessibility guidelines. When using new technologies, ensure that they transform gracefully.
Note. Converting documents (from PDF, PostScript, RTF, etc.) to W3C mark-up languages (HTML, XML) does not always create an accessible document. Therefore, validate each page for accessibility and usability after the conversion process. If a page does not readily convert, either revise the page until its original representation converts appropriately or provide an HTML or plain text version.
Checkpoints: W3C currently has no checkpoints on this guideline with the recommendation that it must be implemented. Refer to the W3C for checkpoints that the W3C recommends should or may be implemented.
Guideline 12. Provide context and orientation information
Provide context and orientation information to help users understand complex pages or elements
Grouping elements and providing contextual information about the relationships between elements can be useful for all users. Complex relationships between parts of a page may be difficult for people with cognitive disabilities and people with visual disabilities to interpret.
Checkpoints:
12.1 Title each frame to facilitate frame identification and navigation. [W3C priority - must implement]
For example, in HTML use the "title" attribute on FRAME elements.
Guideline 13. Provide clear navigation mechanisms
Provide clear and consistent navigation mechanisms to increase the likelihood that a person will find what they are looking for on a site:
- orientation information
- navigation bars
- a site map, etc.
Clear and consistent navigation mechanisms are important to people with cognitive disabilities or blindness, and benefit all users.
Checkpoints: W3C currently has no checkpoints on this guideline with the recommendation that it must be implemented. Refer to the W3C for checkpoints that the W3C recommends should or may be implemented.
Guideline 14. Ensure that documents are clear and simple
Ensure that documents are clear and simple so they may be more easily understood
Consistent page layout, recognisable graphics, and easy-to-understand language benefit all users. In particular, they help people with cognitive disabilities or who have difficulty reading. (However, ensure that images have text equivalents for people who are blind, have low vision, or for any user who cannot or has chosen not to view graphics.)
Using clear and simple language promotes effective communication. Access to written information can be difficult for people who have cognitive or learning disabilities. Using clear and simple language also benefits people whose first language differs from your own, including those people who communicate primarily in sign language.
Checkpoints:
14.1 Use the clearest and simplest language appropriate for a site's content. [W3C priority - must implement]
Appendix A. -- Validation
Validate accessibility with automatic tools and human review. Automated methods are generally rapid and convenient but cannot identify all accessibility issues. Human review can help ensure clarity of language and ease of navigation.
Begin using validation methods at the earliest stages of development. Accessibility issues identified early are easier to correct and avoid.
The following are some important validation methods, discussed in more detail in the section on validation in the Techniques Document.
1. Use an automated accessibility tool and browser validation tool. Please note that software tools do not address all accessibility issues, such as the meaningfulness of link text, of the extent to which a text equivalent applies, etc.
2. Validate syntax (e.g., HTML, XML, etc.).
3. Validate style sheets (e.g. CSS).
4. Use a text-only browser or emulator.
5. Use multiple graphic browsers, with:
- sounds and graphics loaded
- graphics not loaded
- sounds not loaded
- no mouse
- frames, scripts, style sheets, and applets not loaded.
6. Use several browsers, old and new.
7. Use such things as a self-voicing browser, a screen reader, magnification software, or small display.
8. Use spelling and grammar checkers. A person reading a page with a speech synthesiser may not be able to decipher the synthesiser's best guess for a word with a spelling error. Eliminating problems with grammar increases comprehension.
9. Review the document for clarity and simplicity. Readability statistics, such as those generated by some word processors, may be useful indicators of clarity and simplicity. Better still, ask an experienced (human) editor to review written content for clarity. Editors can also improve the usability of documents by identifying potentially sensitive cultural issues that might arise due to language or icon usage.
10. Invite people with disabilities to review documents. Expert and novice users with disabilities will provide valuable feedback about accessibility or usability problems and their severity.
Source: W3C
Send your comments and queries to electronic@gcis.gov.za.