View source for DevSummit07:Engineering for Accessibility and the Differently-Abled

=== Facilitated by Roger Heller, [http://dralegal.org/ Disability Rights Advocates], and Jane Berliss-Vincent, [http://www.cforat.org/ Center for Accessible Technology] ===

Often overlooked in the nonprofit software arena are the needs of those with different physical abilities. 

From web pages that don't work with screen readers and security mechanisms that require visual ability, to applications that presume specific modes of input, many gaps remain in making nonprofit software fully accessible to the broadest range of users.

This session will offer practical tips and resources for designing more inclusive tools.


Background: Disability-related issues on websites -- people who are blind cannot fully access many websites, including commercial websites.  Disability Rights Advocates started getting complaints about Target's website.  They looked into it and discovered that it was a mess for visually-impaired software to read.  They wouldn't voluntarily fix their website, so Roger is suing them.

There is a legal (and ethical) obligation for organizations to make their websites as accessible as possible.  

There is software available to make websites accessible.  Plus, there are considerations to take into account when designing websites.  The software is getting better, so the design needs to keep up.

What does it mean to be an accessible website?  It's not cut and dry.  There are guidelines, however, by a couple of different groups.  They are not identical, and really are meant to be more of a starting point.

World Wide Web Consortium has some guidelines here: http://www.w3.org/TR/WAI-WEBCONTENT/

*Level 1 guidelines - if not followed someone will be unable to use your website
*Level 2 guidelines - if not followed it will be very difficult for some people to use your website
*Level 3 guidelines - if not followed it will be an unnecessary complication to use your website

These are 1.0 guidelines.  There are 2.0 guidelines being developed to account for different technology since the 1.0 guidelines were developed.

Accessibility 101: 

There are many different things that can affect accessibility -- visual imapiredness, carpal tunnel, cognitive disability, low bandwidth.

Graphics -- should have alt attributes which describe the graphics, especially if they are links.  This is important if someone has graphics loading turned off, for example.  This also helps screen readers (used by people with visual disabilities as well as learning disabilities).  Screen readers will read the alt attribute under the picture, so the user of a screen reader will not know what is going on if there is not an attribute for the picture.  (Example given was OfficeMax's website -- some of the links do not have alt attributes -- like the one for "weekly ad").  In the case of a picture which is not necessarily relevent, a "null" alt attribute may be used (such as a picture of a product).

JAWS -- screen-reading software used as an example of what a visually impaired person would be using.  JAWS actually is more beneficial when color-contrast is an issue (ie. grey on grey, yellow on white, etc.)  JAWS doesn't care about colors, so it cna be useful for some sighted (or colorblind) users as well.


Guidelines:

POUR - 

Perceivable -- people have to be able to know that the object on which to be acted on is there.
Operable -- Once found, the object should be able to be acted on.
Understandable -- Users should be able to understand what the objects do when acted on
Robust -- The entire website should be reliable for everyone.


Example of an accessible website -- http://www.davidroche.com

* All pictures have alt attributes
* "Skip Navigation" - link at the beginning of the website that will give the user of a screen-reader the option of skipping through unnecessary links.  It is built into the website.
* Code text as relative units instead of fixed, so that users can increase the text size if they need to

Cascading style sheets -- way to program a wide variety of style elements on the page, so that you don't need to make changes to every single page.  

Keep coding simple -- don't use frames.

There are websites which check the validity of your code, so that you can test your website to make sure it's compatible with screen-readers.

Audio sites -- you can code your website such that if a screen-reader is detected, the audio is disabled so as to not interfere.

Testing for usability -- accessibility should not be done in a vacuum -- it should be done at the same time as the other usability design and testing.  You need to run your website past a representative set of users -- including those who need accessibility.  It is possible to have a perfectly accessible website that is not usable.  You need to test both.

The Center for Accessible Technology can help.  They provide consulting services, which includes a bank of users for usability and accessibility testing purposes.  

http://www.cforat.org/