www.RMIUG.org
March 8th, 2005
"Section 508: The Good, the Bad, and the Not-So-Ugly"

Minutes of the 3-08-05 meeting of the Rocky Mountain Internet Users Group (RMIUG):
"Section 508: The Good, the Bad, and the Not-So-Ugly"

MEETING SPONSORS

MicroStaff (http://www.microstaff.com) provides pizza and beverages. Microstaff also provides creative and technical talent for Web, Interactive Media, Marketing Communications, and Software Development projects.

ONEWARE (http://www.ONEWARE.com) pays for these meeting minutes. ONEWARE is a Colorado-based software company that provides semi-custom, web-based applications.

NCAR provides free use of their facility for our meetings.

Copy Diva (http://www.copydiva.com) provides the audio/visual equipment.

_______________

MEETING MINUTES

Announcements:

The Boulder Writers Alliance is having a meeting on March 22 called "Beyond FrameMaker, The Next Step in Automated Publishing." See http://www.bwa.org for information.

_______________

INTRODUCTION

Section 508 requires federal agencies to make their electronic and information technology accessible to people with disabilities. The law applies to all Federal agencies when they develop, procure, maintain, or use electronic and information technology; it does not apply to nongovernment websites.

If Section 508 doesn't really affect most websites, should we care? Or are there inherent benefits to everyone when you design a website that blind people can use?

About 25 people attended tonight's meeting. The PowerPoint presentation is available by contacting the speaker at ewebb@quintusdesign.com.

_______________

SPEAKER

Erika Noll Webb (ewebb@quintusdesign.com) is a principal of Quintus Design, a consulting firm that designs high-technology products and systems using proven customer-experience research methodologies. Erika earned a PhD in Cognitive Neuropsychology from the University of Illinois at Urbana-Champaign, with a minor in Human Factors. She spent five years as a faculty researcher at the University of Colorado Health Sciences Center where she worked primarily with the elderly studying Alzheimer's Disease and dementia. Erika applies this unique combination of skills and experience to the design or redesign of products for accessibility for companies including Hewlett Packard, Compaq, and Qwest.

_______________

ERIKA NOLL WEBB
Why comply with 508 if you don't have to? Are there other benefits?

I have a consulting firm in town where we focus on understanding the user experience. A few years ago people started asking us about 508 because no one knew what it was all about. So with my background in neuropsychology I made 508 my specialty. This has become more important recently because it's impacting nongovernment websites and technologies.

The biggest problem with 508 is that people get stuck on its details and forget to make their stuff actually usable. The question to ask yourself is "What can I do to make my product easier to use for everyone, not just those who are 100 percent disabled? Don't forget that many people are only partially disabled, not completely blind, deaf, or paralyzed.

What are disabilities?

A disability is anything that impairs your day-to-day life and requires some modifications to the way you do things. For example, just having to wear gloves for a month is a disability. It's a temporary functional limitation, and it's only partially disabling.

One in five Americans has disabilities (one in two for those over age 65). One third of those over 55 have a functional limitation.

24 million Americans have a significant hearing problem; 12 Million have a vision impairment that is not correctable with glasses.

Low Vision

Low vision includes the blind but also people with poor vision. Always remember the "in-between" range of disabilities. Low vision includes myopia (blurring), cataract (yellowing, making it hard to distinguish LEDs), diabetic retinopathy (clumpy blocked vision), glaucoma (tunnel vision), and macular degeneration (loss of the center of the visual field).

Cognitive disabilities

This has a very wide range of conditions. It's difficult to know where to draw the line, at what level of cognitive disability do you decide people can't use your product? Think about someone whose first language isn't English--will they understand your website?

Physical Disabilities

Eight percent of the population has a physical disability due to injury or disease. Broke your leg skiing? You're disabled.

What is Web Accessibility?

Accessibility is very experiential: Can I use the data as effectively as someone who isn't disabled? It is also environmental: Is my browser and assistive technology (like a screen reader) compatible with the website?

The 508 law says to test it with assistive technologies, but it doesn't specify which ones and how many. The best you can do is document what you've tested; don't claim it will work in every scenario.

There are folks out there who will test your site and claim to certify 508 compliance. This is dangerous--you should never "certify" because it's impossible to ensure 100 percent compliance. You can always find some scenario where your technology will be inaccessible. Instead of certifying, document what is accessible about your site, what assistive technologies will work with it, etc. You can certainly hire someone to test your site and document how it's usable.

Accessibility is important to everyone because good design is accessible design. Accessibility can remove hindrances for many and bring about improvements for everyone. For example, if you make your website functional without loading any images, it'll work with PDAs that have crappy screens.

REDUNDANCY IS THE KEY TO ACCESSIBILITY. With redundancy, chances are everyone will find a way to get to your information. It's always good to have multiple paths to your information.

History of Accessibility Laws

In 1968 the Architectural Barriers Act set a precedent such that these laws have no teeth and aren't enforced. Because it was about physical barriers to access it came under the Department of Transportation. This law also set a standard for "barred access"--a concept nearly impossible to prove in court because inaccessible doesn't necessarily mean barred.

The Americans with Disabilities Act of 1990 put teeth into it but it still required class-action suits which mostly benefited lawyers. And you still had to prove barred access. Such cases are exceedingly rare in technology, where it's especially difficult to show barred access. It's a very high legal standard to hit.

There was a rare case in which someone claimed Priceline.com was a web-only storefront making it difficult to purchase things from Priceline any way other than through their website. And their website was not accessible for people with disabilities, Priceline.com was open for scrutiny. In another case someone went after a cell phone maker because no phones had screen readers. So there is something to be said for accessibility as a way to avoid lawsuits.

Section 508 is an amendment to the Americans with Disabilities Act to add information about technology. The debate over the government not wanting to legislate innovation led to a compromise rule that said only government agencies are not allowed to buy inaccessible technologies. So if your stuff is inaccessible, you can still make it but you've lost the government market. The goal of 508 is to ensure that the government's public-access electronic communication and information systems (EIT) are accessible to people with disabilities. An EIT is essentially anything with a computer chip.

Conceptual Breakdown of 508

508 has 16 subparts in three groups that cover:

1- software, web, telecom, multimedia, self-contained gadgets, computers--each with specific standards.

2- functional performance criteria: use without seeing, hearing etc. A window pop plus a beep (remember: redundancy is the key) makes it so you don't have to do just one or the other.

3- Information, Documentation, and Support: support is part of your product and must be accessible.

For the 16 subparts: Three apply to every page, nine relate to assistive technologies being able to access your pages, and four are about precautions. Some of these were derived from W3C guidelines.

If you don't like 508, remember it's still an excellent guideline to making your technology usable in redundant ways.

"Every-Page" subparts

Text equivalents (part a) for pictures

Every nontext visual element should have an alt tag. For things like spacers, alt="" tells screen readers to ignore it. By default, readers read alt, not title tags. Title tags are for mouseover pop ups. You can also use a d-link: a tiny letter d linked to an image description on another page. Screen readers will also recognize the longdesc tag, which provides a skippable link to a description that is too long for an alt tag.

Backward compatibility with older browsers isn't required by 508. If you're making something for the government, you can leave it up to them to specify what browsers your website needs to work with. You can make your own selections and then leave it up to the agency to require more.

Now let's say you've got a complex wiring diagram on an engineering site? Can you possibly describe it in words? Yes, of course you can. Just use a lot of words on a page linked from a longdesc tag. Every image is describable.

Of course not every element has to be alt tagged. If its not important--like for decorative images--don't waste people's time with an alt tag description.

Maps can be very challenging. Check out http://www.traffic.511.org. It gives real-time color-coded traffic conditions on a map of the Bay Area. How do you tag an image that's always changing? You don't. Instead you set up a text-based query that returns a text equivalent for the particular route you're interested in. The text output is maximum, minimum, and average speed for the route, which is very informative. If the minimum speed is 5 mph and the average is 50, you know there's just an isolated slowdown, which is what the map would show you. But blind people don't drive, so what's the point? Turns out they do travel in cars quite a bit (of course), and often they are hiring a car that charges by the hour. So they care about traffic conditions.

But you can't always know what the user is specifically interested in. In those cases you can supply a phone number to call during business hours--not a perfect solution.

Style sheets (subpart d)

Don't use style sheets to present content because not everyone will be using yours. Test your site with CSS disabled to make sure it's readable and you haven't lost any content. http://www.csszengarden.com shows what CSS can do--so be careful about stripping it. An advantage here of using CSS is that you can optimize the HTML for assistive technologies while using CSS for create the visual presentation.

Skip navigation

Skip navigation links allow people to skip over redundant links, such as those appearing on static menus on every page. Skip links will bounce you straight to the main content. It's best to accomplish this with CSS.

Multimedia alternatives (subpart b)

You must provide equivalent alternatives for any multimedia presentation (content video) and it must be synchronized with the presentation. Captioning or a transcript suffices for non-live presentations. But if it's live, providing a transcript tomorrow isn't equivalent. You have to use a captioned webcast.

Don't use server-side image maps because they aren't accessible and, with today's browser technology, there's no reason to use them anyway. Use client-side maps only.

For data tables like a bus schedule, use headers in row 1 and column 1 only. For larger or complex tables, use the header attribute to connect header information to each cell, so that the screen reader includes headers in reading each cell--don't make people memorize more than about seven items at a time.

If you're the rare person that uses frames, name your frames with descriptive terms.

When using scripting languages to display content, the information provided by the script should be identified with functional text that can be read by assistive technologies. If you're using scripts to do mouseover links, for example, put in redundant text somewhere so that your links aren't only accessible with a mouse.

Javascript: use alt tags, test things without a mouse (onChange, onMouseover, etc). Confirm that text output is readable by a screen reader.

Applet/plugins--provide a link to the plugin download--providing keyboard access is a good usability standard.

In forms, always use the label element. Also arrange fields to be screen-reader friendly so the reader presents the fields in a logical order; arranging things vertically or horizontally will make a difference for screen readers.

Avoid conveying information with only color. Use redundant text and symbols in addition to any color coding. Maximize contrast. For maps that do use informative color, you can provide high-contrast maps, special versions for certain kinds of color blindness, etc.

Screen flicker (refresh rate) under 55 Hz can cause seizures.

Don't time people out; give extra time to respond.

I am available to answer any questions and I can also provide consulting services. Feel free to contact me about how to code this stuff or anything else.

=======================

RMIUG (http://www.rmiug.org/) appreciates the sponsorship of
MicroStaff (www.microstaff.com), ONEWARE (http://www.ONEWARE.com), and Copy Diva (http://www.copydiva.com).

Select a Year

2008 Minutes
2007 Minutes
2006 Minutes
2005 Minutes
2004 Minutes
2003 Minutes
2002 Minutes
2001 Minutes
2000 Minutes
1999 Minutes
1998 Minutes
1997 Minutes
1996 Minutes
1995 Minutes
1994 Minutes

Copyright 2004 RMIUG.org, All Rights Reserved