Accessibility

Kevin Lawver

This is a presentation. If you'd like to view all the slides like a normal web page, you can.

Accessibility: A Technical Introduction

• Accessibility is for everyone:
  • 60% of working-age Americans would benefit from the use of accessible technology
  • 66.7 million internet users would benefit from improvements at AOL and Time Warner
• Some Numbers:
  • Users with disabilities are about three times less likely to succeed than users without disabilities in carrying out such routine Web tasks as searching for information and making purchases. (Coyne and Nielsen - Beyond Alt Text
    - 2001)
    

Accessibility Basics

• The blind use screen readers like JAWS
• Partially sighted (you know, who have glasses, like me) benefit from larger fonts, screen magnification and better screen contrast.
• Hearing impaired people can't rely on sound-only queues that something has happened.
• Color-blind people need greater contrast in colors to differentiate.
• Use title attributes for content that isn't adequately described (like acronyms and abbreviations).

The Standards

• W3C's WAI Group
  • WCAG 1.0
• Section 508

Accessible Images

• All images should have alt attributes
• All non-semantic images should have empty alt attributes.
• Images within links should have unique alt attributes.

Example: Accessible Image

<img src="aol.gif" alt="America Online"/>

• See? That wasn't hard, was it?

The Problem With Tables

• Tables are meant to be read in 2 dimensions.
  • Screen readers read from left to right, top to bottom.

Accessible Tables

• Never use tables for layout.
• Use table headers
• Use caption and summary
• Use tbody, thead and tfoot (if applicable).

An Accessible Table From The Ground Up

• We're going to do a fake bus schedule.
• Here's the simple view
  • No accessibility information has been added at all.

Step Two: Table Headers

• Let's add table headers
• See?

Step Three: Summary and Caption

• Caption provides a visual explanation of the data in a table.
• Summary provides instructions for how to read the data of the table.
• Our example, with caption and summary.

Step Four: Abbreviations, thead and tbody

• Abbreviations are hard for screen readers to decipher unless they're marked up correctly using the abbr element.
• The same goes for acronyms (using acronym).
• Let's go look

Summary: Tables

• Describe the data in the table in the caption element.
• Describe the interaction in the summary attribute.
• Use proper row and column headers (th)
• Don't forget to explain acronyms and abbreviations.

The Problem With Forms

• Screen reader users interact with forms in a special mode called forms mode.
• Users with mobility problems can have a hard time selecting radio buttons that are too close together.
• Form fields need description that often doesn't exist.

Accessible Forms

• Use fieldsets
• Use legends
• Use labels
• Use title attributes on input fields without labels.
• Use tabindex

Accessible Form Example: The Profile

• Let's build a complex form, and then make it both look good, and make it accessible.
• We'll ask for some personal info and some interests.

Forms: Step One: The Fields

• Here's step one, with just labels and fields
• Looks pretty horrible, huh?

Forms: Step Two: Some Semantic Improvements

• We're going to add fieldsets to break up the form into logical sections.
• We'll put related elements into lists.
• Looks a little better

Forms: Step Three: Tab Order

• We should be OK the way we are, but we'll do it anyway.
• We'll look, but I'm sure it's OK

Forms: Step Four: The Look

• Our form may be accessible, but it looks like crap.
  • Let's remove the bullets from our list of checkboxes and radio buttons
  • Let's clean up the fieldsets, and break the form fields up a bit.
• Let's fix that

Summary: Forms

• The visual design of forms is just as important as the markup.
• Provide enough space between elements so users can "hit the target".
• Provide enough information for an element that a user who tabs into it with a screen reader will be able to tell what they need to do.

Accessible Navigation

• Make it accessible from the top of the document.
  • Use hidden skipnav and skiptonav links
• Use descriptive text in navigation links
• If images used for navigation, should have descriptive alt attributes.

Skiplinks

• Create a list of links as the first element in the body:

<ul id="skiplinks">
 <li><a href="#content">skip to content</a></li>
 <li><a href="#search">skip to search box</a></li>
</ul>

Skiplinks: CSS

• Use CSS to hide the links from everyone else:

#skiplinks {
  position:absolute;
  width:1px;
  height:1px;
  overflow:hidden;
}

An Approach to Accessible Buttons

• Use text replacement to insert graphical buttons.
• Provide descriptive text, just like you would with an alt attribute.
• Use CSS to move or hide the text inside the link.

Example Button

<a href="javascript:self.close();" class="button x" 
title="close this window">close this window</a>

Some Caveats

• To do this, the link must be a block element:
  • use display: block
  • or float it.
• You could do the same thing an image and alt text.
  • But, you'd have to change markup to change the image.
  • With CSS you can use a single image sprite for all your buttons.

Accessible Javascript

• It can be done... really.
• We need to work on this as more and more of our applications go interactive (you know what I mean).

Things to Watch For With Javascript

• Does it still work when you use the keyboard to navigate?
  • onmouseover, onchange, etc, will all break.
  • provide alternative behavior.
• How do you alert the user that information has been updated?
  • I don't have a good answer for this one.
• Use device independent event handlers
  • onfocus and onblur instead of onmouseover and onclick.

There's A Lot More

• I didn't have time to do enough on javascript and accessibility.
• We'll cover it in more detail in a future presentation.
• More Information:
  • Creating Accessible Javascript
  • Accessible DHTML Technology Preview

Accessibility Testing

• Use tools:
  • WAVE Test
  • TOM (currently internal to AOL, will be moved soon)
• Turn off CSS and see how it flows.
• Get a license for a screenreader and get the page read to you (you can get one at the Sensations site).
• Ask for help:
  • Post a question on the WSAG Site
  • Ask Tom or Don for a review

Other Reading

• AOL Sensations - AOL's accessibility office maintains the documents on this site.
• Accessify
• Accessible Net
• Guild of Accessible Web Designers
• Web Accessibility Initiative
• Building Accessible Web Sites by Joe Clark
• Maximum Accessibility by John M. Slatin and Sharron Rush

Conclusion

• Accessibility is not optional.
• Save yourself a lot of trouble and use standards - gets you halfway there.
• It's not hard if you think about what your document means