Optimizing websites for the blind

Let's talk about interface elements, validation, and Sec. 508.

Moderators: rcrisler1, saltybeagle

Optimizing websites for the blind

Postby Erin Paseka » Wed Sep 24, 2008 11:54 am

Suggestion: Provide information on optimizing websites for blind people.

Once upon a time, a blind applicant emailed me to point out that our website (in particular the Application for Graduate Admission) was not very blind-friendly. For example, if we have form fields arranged in a table and we don't have each field individually described with tags/attributes that the aural browser reads aloud, it can be hard for a blind person to determine what they're supposed to put in a field.

Such things had never crossed my mind. Right away I called Services for Students with Disabilities and made an appointment with someone who was going to help me figure out how to make our pages more blind-friendly. As I arrived for the appointment, this person took a phone call and continued to gab, knowing I was waiting. After 15 minutes someone else took pity on me and turned me loose on a computer with Jaws. I'd have been fine with some learning by trial and error, except they were having registration/validation issues with their copy of Jaws and it died repeatedly. Meanwhile a low-vision student was hovering, waiting to use it. Eventually I gave up and left, without having gained any useful knowledge.

I feel bad knowing I haven't made this better. But I don't have time/funds to buy Jaws and learn what works, what tags/attributes it speaks, whether its competitors have the same behavior, etc. Nor patience to go back to SSD.

It would really help if UNL had a go-to person who knew the behavior of the major aural browsers and could review a site and point out things that are not blind-friendly. It would also be helpful to have a resource (maybe a wiki page) listing common web dev mistakes and how to avoid/fix them, for those of us who don't have aural browsers and can't "see" for ourselves what works. (You'd think such a page would already exist but I'm having no luck with Google.)

</novel>
Erin Paseka
 
Posts: 147
Joined: Tue Jul 13, 2004 3:02 pm
Location: Graduate Studies

Postby beck » Wed Sep 24, 2008 2:26 pm

I could be wrong, but I think Brett's great form styling examples on the wiki will work with aural browsers (having the fields labeled and tagged appropriately) and avoids use of tables altogether to join labels and fields very closely.

I know that only addresses a specific part of making sites accessible to blind users. Maybe it can save you some pain with JAWS.

Bryan
- Bryan
beck
 
Posts: 41
Joined: Thu Oct 06, 2005 11:02 am
Location: VCSA

Postby bbieber2 » Thu Oct 02, 2008 1:30 pm

Hey Erin,

Good questions... I don't have any great answers... but, here's a tool which might help you.

This was featured today on Paul Boag's web design podcast (http://firevox.clcworld.net/about.html), and it's a free screen reader for Firefox -- look out Jaws!

http://firevox.clcworld.net/about.html

I'd encourage users to try it out.. turn it on, shut the monitor off and actually try to navigate a site.
bbieber2
 
Posts: 58
Joined: Mon Nov 05, 2007 1:28 pm

Postby Erin Paseka » Thu Apr 22, 2010 5:57 pm

(Reviving old thread)

1. FireVox: Does anybody have this (or anything similar) working with Firefox 3.6.3? I could've sworn I had it working a couple browser versions ago, but now I can't get it to make a sound.

2. WAVE Toolbar: Has anybody used this in "experimental" status and lived to tell about it? I really can't afford to blow up my computer with buggy beta stuff right now.

3. Alt vs. label, Cynthia vs. WAVE: In a form, are alt attributes on inputs sufficient, or do we really have to use all those gross label tags? If I use Cynthia Says, alt tags pass in 508 or WCAG modes. Now people are telling me that alt tags fail in WAVE, but I don't know where any rule says that alt tags aren't good enough, or whether that rule is one that we should/must follow.
Erin Paseka
 
Posts: 147
Joined: Tue Jul 13, 2004 3:02 pm
Location: Graduate Studies

Postby smeranda » Tue May 25, 2010 3:07 pm

i/r/t the alt vs. labels:

The alt attribute is only supposed to be used as a text alternative for image inputs, it isn't supposed to be used to control accessibility. Screen readers will not use it on other input types.

The label attribute is the accessible markup for a form and comes with a major added usability advantage: text inside a label associated with an input (or textarea or select) becomes clickable and switches focus to the input!

It is best practice to use label for inputs, and has been a requirement of WCAG since the first draft: http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels

All the form styles available in the templates (including the new an improved zenforms) support/require labels: http://www1.unl.edu/wdn/wiki/Zenform
Seth Meranda
User Experience Architect
University Communications
(402) 472-8513
seth@unl.edu
smeranda
 
Posts: 111
Joined: Tue Apr 05, 2005 2:34 pm
Location: University Communications


Return to Usability/Accessibility

Who is online

Users browsing this forum: No registered users and 0 guests

cron