Accessibility

Guideline 1: Provide text equivalents of images and/or auditory content.

Provide content that, when presented to the user, conveys essentially the same function or purpose as auditory or visual content.

What this means to you: you must remember to include alt tags for all your images, including spacer gifs (images which exist only to create space between other page elements). The text included in the alt tag is what shows up when the image fails to download. It is also the only part of the image that can be read by a assistive browsing devices, such as speech synthesizers.

Additionally, provide alternate text for auditory content. If your web page contains a sound clip, remember to include the lyrics.

Lastly, provide text equivalents for all image maps, and images used as links. And don't forget to use the alt tag for imagemap "hotspots" (the clickable regions of the image map)

Guideline 2: Ensure that text and graphics are understandable when viewed without color.

Light colored text must be paired with a dark background, and vice-versa. For example, the graphic at the top of this page that says "resources" is written in a light green, and placed on a much-darker green background. Special care was taken to ensure that these two colors were sufficiently high contrast.

Guideline 3: Use (html) markup and (css) style-sheets, and do so properly. Separate structure and presentation in your web documents.

"Using markup improperly -- not according to specification -- hinders accessibility. Misusing markup for a presentation effect (e.g., using a table for layout or a header to change the font size) makes it difficult for users with specialized software to understand the organization of the page or to navigate through it. Furthermore, using presentation markup rather than structural markup 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 to other devices". Web Content Accessibility Guidelines 1.0

Quite honestly, this is one of the most difficult accessibility guidelines to comply with, largely because support for Cascading Style Sheets (CSS) is buggy and browser specific. In an ideal web environment, HTML would be used only as it was intended: to markup text into headers, sub-headers, quotes, emphasized text, and of course, links. Cascading style sheets would then be used to control all of the presentation elements, such as layout, alignment, italics, etc. All HTML tags which control layout (such as the bold and center) tags would be rendered obsolete. This, however, is not an ideal web environment.

Nonetheless, there are some simple things you can do to separate structure and presentation in your documents. First, make an outline of your document. Second, recognize that each point in the outline represents a structural change. Third, use structural elements first to mark these points (i.e. headers, lists, etc.), Fourth, if necessary use presentation elements (bold, italics, etc) to make the changes more visually striking,

One of the easiest ways to achieve the separation of structure and presentation is to stop using header <H1, H2, H3, etc.> tags (structure) to change font size (presentation). Conversely, don't use a tag when you should really be using a

Also, use relative (-1, +6) instead of absolute (2, 4) sizes when specifying font size. Remember, some viewers adjust their browser settings to increase the default font size. If you specify your fonts in absolute sizes, you deny your viewer control over their web environment, and might alienate some of your audience.

Guideline 4: Clarify natural language usage. Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text.

Clearly identify changes in the natural language of your document. If you switch from English to Spanish in your documents, clearly identify this change. Also, you should clearly identify the natural language of the document in the document's html headers. Lastly, be sure to explain all abbreviations and acronyms.

Guideline 5: Ensure that tables have necessary markup to be transformed by accessible browsers and other user agents.

The WAI recognizes that many developers use tables for layout, and will continue to do so until CSS is fully supported by the leading browsers. Layout tables, however, can present problems to users relying on screen readers (primarily blind users). Nonetheless, there are steps that can be taken to ensure accessibility of all tables.

Layout tables. Make sure your tables make sense when ready linearly (line by line). If your tables don't make sense when read linearly, reformat them, or do away with them completely.

For data tables. identify row and column headers. For example, in HTML, use TD to identify data cells and TH (table header) to identify headers. For data tables that have two or more logical levels of row or column headers, use markup 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, and the "axis", "scope", and "headers" attributes, to describe more complex relationships among data. "

Guideline 6. Ensure that pages featuring new technologies are accessible even when newer technologies are not supported or are turned off (this is referred to as "transforming gracefully.").

This one is pretty straightforward. We all like bells and whistles (applets, Javascript, Shockwave, Flash, PDF files, music, etc.), but make sure your web page still makes sense without the bells and whistles. Remember, your bells and whistles won't work on older browsers, won't work on alternate user agents (speech synthesizers and Braille devices) and won't work if someone has chosen to disable those features (and believe me, people do turn off javascript and skip over flash presentations entirely)

So if you use cascading style sheets, organize documents so they can still be read without style sheets. Also ensure that there is equivalent accessible content for all dynamic features (movies, sounds, flash, cool javascript rollovers), and that this content is updated whenever the dynamic content changes. Do the same for all images and auditory content (see Guideline 1).

As for javascript and Java applets: ensure that your pages still work when these features are turned off. As a matter of fact, count on these features being disabled. That will prevent you from making a javascript based navigation menu, which is one of the least accessible things you can do. It's a bad idea. Don't do it.

Guideline 7: 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." (From the Web Content Accessibility Guidelines 1.0)

Don't forget: Movement included pop-up windows. Pop-up windows create difficulties for users with cognitive disabilities. Also, changing the current window or popping up new windows can be very disorienting to users who cannot see that this has happened. If you feel that you must use a pop-up window, warn the user ( a simple "clicking on this link will cause another window to pop-up should suffice)

Lastly, flashing screens can cause seizures. Enough said.

Guideline 8. Ensure direct accessibility of embedded user interfaces. Ensure that the user interface follows principles of accessible design: device-independent access to functionality, keyboard operability, self-voicing, etc.

This will only come up if you embed content (embedded movies and sounds, applets, etc.). If you do, make sure that the interface of the embedded object is as accessible as the browser interface itself.

If this is not possible, provide equivalent context in an accessible page.

Guideline 9. Design for device-independent access. 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 browser or the page itself with whatever input (or output) device they chose (mouse, keyboard, voice, head wand, etc.).

So here's what you do. Provide text equivalents for all image maps and images used as links (see also Guideline 1). Also, don't use client-side image maps instead of server-side image maps.

Guideline 10. Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly.

Remember, not everyone takes the time to update to the latest and greatest browser. So that CSS styled, javascript enabled, Flash-dominated website that looks great on your browser, may just be a big mess on someone's IE 3.

Problems with emerging technologies are compounded for users relying on assistive technologies. Older Braille readers and speech synthesizers are often quite quirky. And even the most advanced reader might not know what to do with the content in a pop-up window. The reader might abandon the original document entirely, or ignore the pop-up window, either of which would be disorientating for users who cannot see what has happened (see Guideline 7 for more on this).

So until the time arrives when all users rely on the latest browsers, and assistive technology addresses all the current issues, make sure you're pages degrade gracefully and are as accessible as possible.

Guideline 11. Use W3C technologies according to specification and follow accessibility guidelines.

As of this writing there are only two w3c technologies (HTML and CSS). All of the others (Flash, Shockwave, Quicktime, Real Audio, PDF files) cannot be displayed by your web browser without the aid of a plug-in. A plug-in is a program that operates in conjunction with your browser to display non w3c technologies. Plug-ins are company (and file-format) specific. Needless to say, not everyone has every plug-in, and not everyone wants to download the ones they don't have.

Of course, we're going to use non-w3c technologies anyway. Who are we kidding. Everyone wants sound files, and movies, and 300 page PDF documents. Just make sure to provide an alternate version of the content that is accessible. So if you have a PDF file, you better have an HTML file as well. And don't forget to update this equivalent page as often as the original.

Guideline 12. Provide context and orientation information to help users understand complex pages or elements.

Title each frame to aid navigation and orientation. Make sure these titles are meaningful, and clearly relate each frames relationship to others. Also consider offering a no-frames version of your page. Better yet, don't use frames at all.

Guideline 13. Provide clear and consistent navigation mechanisms -- orientation information, navigation bars, a site map, etc. -- to increase the likelihood that a person will find what they are looking for at a site.

This is my favorite guideline. Adhere to it always. To quote the venerable WAI "Clear and consistent navigation mechanisms are important to people with cognitive disabilities or blindness, and benefit all users".

Try to look at your site as if you had never been there before. Would it still make sense? Could you find your way around? Can you at least get back to the home page? If not, you have your work cut out for you.

I can offer some basic guidelines, which will help improve navigation

1. Create a navigation scheme. A popular one is a table with links to each of your site's main sections (See the Rhode Island Training School Information Page for a great example).

2. Make sure the navigation scheme is text based, or at least has nearby text equivalents.

3. At the very least, each page must have a link back to the main page. This is non-negotiable.

4. Pay attention to links. Clearly identify the target of each link. Link text should be make sense when read out of context -- either on its own or as part of a sequence of links. Link text should also be short. The words "click here" should never be a link.

Compare this link: Click here to email the webmaster with this link: Email the webmaster.

Both links will send email, but only the latter makes sense out of context.

Guideline 14. Ensure that documents are clear and simple so they may be more easily understood.

Clear and simple language promotes effective communication. It eases information access for people with cognitive disabilities, and for people whose primary language is not your own (including sign-language speakers).

Use the clearest and simplest language for your site. Your users will appreciate it.