On May 5, 1999, the W3C came out with a recommendation on Web Content Accessibility. This recommendation explains how to create Web content that is accessible to people with disabilities.
But why create accessible HTML? As long as most people can read your page, who really cares, right? Well, if you're trying to make money on the Web, perhaps now you aren't having any trouble, but what's going to happen when the hype dies down and there are so many e-commerce pages on the Web that your little domain is just one of millions? If your site is accessible now, you will have loyal buyers later.
Some things to note about writing Web pages that meet the accessibility guidelines:
- These guidelines are not difficult. The hardest part about them is remembering them.
- As the W3C says
"following them will also make Web content more available to all users"
The Accessibility Guidelines
- Provide equivalent alternatives to auditory and visual content.
While some people may not be able to see or hear your images or sound, your Web page should have an equivalent, rendered in text, so that their browser can interpret it. For example, if you use images for your navigation, you should have text explanations and links that serve the same purpose. - Don't rely on color alone.
Use a visual clue other than just color to convey information (such as required fields on a form). Also, make sure that the colors you choose have sufficient contrast as to be legible. - Use markup and style sheets and do so properly.
Even if an HTML element works without following the specification, you should follow the spec in order to maintain accessibility. For example, Internet Explorer will display tables which are missing the final </table> tag. However, tables formed in this fashion are inaccessible. Also, if it is appropriate to use a table tag or other markup use it, rather than using approximations such as creating a table-like structure with the <pre>; tag. Use HTML, rather than images where appropriate and the markup exists to do so. - Clarify natural language usage.
Identify the language in the head of the document using the lang attribute. Also, make sure that you specify abbreviations within a document the first time they occur. You can do this using the title attribute of the <acronym> and <abbr> tags. - Create tables that transform gracefully.
Tables should be used to markup tabular information rather than for purely design purposes. If you are going to use tables for layout, try to create tables that make sense when linearized, or else provide a non-tabled version of the page. Provide summaries for tables of data. - Ensure that pages featuring new technologies transform gracefully.
When you write HTML on the bleeding edge, make sure that older versions still work when viewing the page. This will also impact people with newer browsers who choose to turn off features (such as Java, JavaScript, images, etc.). - Ensure user control of time-sensitive content changes.
Specifically, it can be difficult to read blinking, moving, animated text. These features should either have a way to be stopped by the viewer, or an alternative page that is not moving. - Ensure direct accessibility of embedded user interfaces.
In other words, all interfaces that are embedded into your page (applets, plug ins, etc.) should follow these guidelines for accessibility as well. - Design for device-independence.
Make sure that your page can be viewed with any input or output device that the reader chooses. Things like text links as an alternative for image maps make pages accessible for readers who don't use a mouse. - Use interim solutions.
These solutions are specific to the nature of the Web at the time of the writing of these guidelines. There are several suggested interim solutions, such as:- do not use pop-up windows
- make sure that form labels immediately precede the control
- provide a linear text alternative to all tables with text in parallel, word-wrapped columns
- include default characters in edit boxes and text areas
- include non-link, printable characters between adjacent links
- Use W3C technologies and guidelines.
If you can't use a W3C technology, then provide an alternate version that is accessible. - Provide context and orientation information.
Do things like give your frames titles, and describe their purpose and relationship to each other (if it's not obvious from their titles). Also, you should divide large blocks of information into smaller chunks. - Provide clear navigation mechanisms.
Stay consistent in your navigation structure. Also, the text of the links should make sense out of context. (e.g. out of context, where does the link "Get Web Design help from About.com" probably take you? What about "click here"?) - Ensure that documents are clear and simple.
This is true of all writing, whether you are striving to be accessible or not. If your information is clear then it will be more accessible than if it is full of jargon and incomprehensible language.
Accessibility is really not difficult. Essentially, it comes down to a choice to take a few extra steps to either provide an alternative to an inaccessible item on your page or find an accessible method of doing the same thing.
