Accessibility Guidelines for Web Standards

bubble

A brief description, or 'rules of the road'!

This document references Web Content Accessibility Guidelines 1.0 from the World Wide Web Consortium.

If you want to make yourself popular in the workplace, get a stick, write the word 'Accessibility' on it, and start beating your fellow website designers about the head with it. If nothing else it will get you noticed.

That's how accessibility rules are generally viewed, as something to be feared, to cower away from, but that's really not the case. The guidelines as laid out by the W3C are there for the benefit of all. They are there to make the web a better, friendlier, easier to navigate place, and that's got to be a good thing, right?

What would you think if you were looking to buy a car and found one you liked the look of on a car lot, but none of the switches had labels on them to tell you what they were, and lights weren't fitted because you probably won't use it at night? I'm guessing you would probably look at the car next to it, even if it didn't look quite as nice, because it does have labels, and it does have lights, and therefore it won't lead you into confusion and frustration when trying to drive it.

Or what if you were selling a car, say a nice Silver BMW? Would you place an advert in the paper stating that you only wanted people who loved Silver BMW's to come and view it? Of course not. Why would you want to alienate such a large group of people and risk losing out on a potential sale?

Accessibility is the same thing. It's basically just common sense wrapped up in some fancy jargon and reams of text. Once you can get through all of it (and believe me that's no easy task) then you will find out that it does indeed make a lot of sense, and best of all, it really does work.

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.

These guidelines are not difficult. The hardest part about them is remembering them. Below is a brief synopsis, or bullet points, of the most important rules and what they mean. Read, digest, remember, and most importantly use them, and in doing so, enjoy the rewards of your now fully accessible website.

The Guidelines

1. 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.

2. Don't rely on colour alone.

Use a visual clue other than just colour to convey information (such as required fields on a form). Also, make sure that the colours you choose have sufficient contrast as to be legible.

3. Use mark-up 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 mark-up 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 mark-up exists to do so.

4. Clarify natural language usage.

Identify the language in the head of the document using the LANG tag. 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.

5. Make tables that transform gracefully.


Tables should be used to mark-up tabular information rather than for purely design purposes. If you are going to use tables for layout, try to build tables that make sense when linearized, or else provide a non-tabled version of the page. Provide summaries for tables of data.

6. 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.).

7. 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.

8. 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.

9. 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.

10. 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 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

11. Use W3C technologies and guidelines.

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

12. 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.

13. 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 HTML help from About.com" probably take you? What about "click here"?)

14. 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.

For a full description of the guidelines please visit Web Content Accessibility Guidelines 1.0 from the W3C.

bubble

Posted on Wednesday 30th July, 2008 at 1:02 pm by Paul Whitrow, and filed under and

There are no comments yet for ‘Accessibility Guidelines for Web Standards’