« Mission iPod: Don't Suck | Main | E-mail from Sam »

Disability support

Hello everyone!
I sent an e-mail to Stacy Smith of Disability Support Services here at K-State. I am going to copy and paste our e-mail back and forth. WARNING: This is an incredibly long e-mail, but it brings up many useful points, so it's worth reading
Cheers!
Heather

Heather -

Wow; lots of questions! First, thanks for considering students with
disabilities. Second, let me see what I can do on the rest.

I think I have a basic handle on what you are trying to do: essentially
to provide an interface for people to be able to use the web page to
send email; make, store and link to videos; and possibly to call public
figures on the phone?

I believe that there are two separate issues at work here with regards
to disability. Let me try to answer them individually.

First, the web site you are building should be accessible in and of
itself. The web site is the user's access to the content you're
wanting him or her to use, and if the site itself isn't accessible, it
won't matter what you do with anything else.

Think of it in these terms: you're going on vacation and you've found a wonderfully accessible hotel. If you can't drive the car because the
CAR isn't accessible, that lovely accessible hotel isn't going to do
you a bit of good.

Fortunately, making web pages accessible requires a combination of good web design sense and good code. All of the information on this is freely available and only costs whatever time it takes you to learn
what it is and how to implement it. Examples include: don't make
things flash/flicker (you can trigger seizures in some people). Always
use alt text to describe important images on your site, and if the
images aren't important, put in a null string (" ") so that speech
readers will ignore it. Don't use "click here" for your links - make
your link the document/page name instead. Make sure that changes on your web pages are always "announced" in some way - or in other terms, don't make any changes to the web page without telling the user. This means that newer programming practices such as AJAX may not work. Make sure the site can be navigated with a keyboard. This last may mean that some JavaScript controls have to be modified. For example, onMouseOver does nothing if you're using a keyboard. Have you noticed that some sites have a "go" button next to a drop-down list that you have to click before the new page will load? This is an accessibility thing - instead of using JavaScript to load the new page when the user releases the mouse button, the user must deliberately click a link.

K-State has some good pages that can help with these basic things, and there are tons of good resources out there from other entities. I've pulled together some resources (including the K-State links) on a page that you might find helpful:
http://www.k-state.edu/dss/k-access/web_page_accessibility.html

Second, on to the content - the bells and whistles. First, the variety
of tools that you plan to offer is very nice, and the good news is that
by offering a variety, you reach a wider range of people. A deaf
student can write an email OR make a video - you might be surprised how many video blogs are out there with people signing. Many students with mobility impairments will be fine as well. Since you are about creating content - not about being a repository for content - then you don't have to worry so much about captioning or providing text transcripts.

The tricky part comes in when your user is blind and uses text-to-speech software or has an impairment that requires navigating the site using speech recognition software. Let's start with text-to-speech.

Text-to-speech, or screen reading software, relies on the structure
within your site's code to "know" what to read and how to read it.
Navigation is generally entirely keyboard-based and relies heavily on
the tab key and many keyboard shortcuts. If elements are not coded
properly - for example, if form fields don't have labels assigned to
them - then the screen reader will not "see" anything and will not be
able to tell the user what's going on. Imagine trying to fill out a
form with your eyes closed....but when you tab to the next field the
computer says "text box" but you don't know what's supposed to be *in* the text box. Text-to-speech readers are exactly why your site
shouldn't do anything that isn't "announced" (like pop up a new window) - the user can't see it and therefore doesn't know anything happened.

Some programs are more friendly to text-to-speech software than others. Most email programs will work fine....except Webmail, which only works halfway. A good rule of thumb to start off with is this: do NOT override a browser's default settings or behavior. The screen reader software is built on those default behaviors being there. Changing them is bad design and will lock some users out of your site.

Speech-to-text users rely on their voice to manipulate software (open, close, open menus, etc) and to dictate text. Users may have mobility impairments that limit or prohibit their use of a mouse or keyboard. Again, you want to make sure that the software you're using will work with these programs - the most popular is Dragon Naturally Speaking. Whether or not your software will work with Dragon would be an excellent question for the folks at Nuance, who have a technical support team.

I might suggest that you offer people the option of recording video OR just recording audio. Some people - disabled or not - want to be heard but aren't so keen on being seen.

Now - as for the cost and difficulty questions, I have no idea. Those
questions are better answered by vendors or groups that are working on that particular software and/or in that particular application. Check out the Skype webpage, for example, for accessibility. The Yahoo JavaScript library has a whole accessibility initiative. There are
TONS of good people out there who will be very excited to learn that
you're thinking about accessibility up front and who will bend over
backwards to help you. When you have specific questions about software and/or applications, I may be able to put you in touch with specific people who have better advice. Let me know when you get to that point.

Thanks, and good luck!

Stacy

TrackBack

TrackBack URL for this entry:
http://ehub.journalism.ku.edu/admin/mt-tb.cgi/3654

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

About

This page contains a single entry from the blog posted on September 11, 2007 4:06 PM.

The previous post in this blog was Mission iPod: Don't Suck.

The next post in this blog is E-mail from Sam.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.35