Below are the minutes for the meeting for the March
8th RMIUG Meeting: "Section 508: The Good, the Bad,
and the Not-So-Ugly"
Let us know if you have any comments or questions:
>>>>>>>>>>>>>>>>>>>>>.
Section 508: The Good, the Bad, and the Not-So-Ugly
8 March 2005 Meeting Minutes
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.
Copy Diva (http://www.copydiva.com) provides the audio
visual equipment.
NCAR provides free use of their facility for our
meetings.
ANNOUNCEMENT
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@....
SPEAKER
Erika Noll Webb (ewebb@...) 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.