The Web Accessibility Evaluation Certificate program is designed as a way for usability professionals to:

• Expand their “toolkit” of professional practice to include accessibility.
• Understand the standards, guidelines, and US and international laws that apply to accessible information technology.
• Learn a set of tools and benchmarks to gauge success in the implementation of accessible design goals from a user perspective.
• Gain skills needed to accurately assess and report on web application compliance to standards and best practices in accessible web design.
• And prove to their companies that they have gotten the training they need to do all this.

More information, check out UPA Voice February 2009 article about the Web Accessibility Evaluation Certificate program or the 2009 Access U curriculum and course descriptions.

The Web Accessibility Evaluation Certificate program advisory board includes:

• Leaders
  • Whitney Quesenbery and Paul Sherman (UPA past-presidents)
  • Sharron Rush (Knowbility)
• Members
  • Cindy Lu (UPA Member)
  • Karen Mardahl (STC AccessAbility SIG)
  • Amanda Nance (UPA Board of Directors)
  • Mike Paciello (The Paciello Group)
  • Ginny Redish (Redish & Associates)
  • Sarah Swierenga (MSU Usabilty and Accessibilty Center, UPA representative to TEITAC)
  • Gregg Vanderheiden (The Trace Center)
  • Kate Walser (CX Insights and member of TEITAC).

Notes:

• For simplicity sake, I’ll refer just to JAWS in this post. Window-Eyes and others work well also -  JAWS just happens to be what I learned and have used most often. The steps below will work for others too.
• Though I love my Mac, I don’t use screen readers on it and am not sure yet how to do this on a Mac. I suspect there’s a way, so if you know, feel free to share!

Background

I work with customers and project teams to see how accessible their products are to people with disabilities. I do some basic things first like check that anything that a user should be able to touch (navigation, forms, etc.) is keyboard accessible and that code is valid and well-formed, with no major issues that would hobble an assistive technology like a screen reader. If it passes those tests, it’s on to a screen reader to see how well an assistive technology can handle it.

Dunh dunh dunh dunh… Imagine the theme song from “Jaws” playing for a moment. That’s about how it feels when you’re trying to listen, process, and jot down what JAWS is reading and where it’s reading. Like you’re about to be attacked by a shark. And inevitably, or at least in about 95% of the times I was testing products, just as I was about to make the big breakthrough and figure out what JAWS was reading, the phone would ring, someone would stop in, or it’d be fire alarm testing day at work.

Every time I’d reload the page or try and dig up my cheat sheet of JAWS keyboard shortcuts and remember which one I needed to use, I’d think “there’s got to be a better way.”

There is.

Recording Screen Reader Output

What if you could record what JAWS says on its first run through and not need to have it repeat each time? That’d save time, wouldn’t it? I hear what you’re thinking – “you mean like put up an old-school tape recorder or new-school MP3 recorder next to the speaker and record it? That seems klugy.”

Nope. Even easier than that, and more elegant.

You can internally route the sound output as an input for the microphone. “What?” That’s right. No new cables, wires, or even external speakers required.

A big thank you to YouTube user ‘pbj746′ for cluing me into this one.

What You’ll Need

1. PC with Windows OS and a sound card
2. Sound recorder software (check Start > Programs > Accessories – there’s usually some basic movie maker or sound recorder tool that comes with the OS). If you don’t have one, try Audacity, an open source sound editing and recording tool.

Set Up to Record Audio Output

1. In Windows, go to your Sound control settings, either by going through Control Panel or by right-clicking on the sound icon in the lower right.
2. In the Sound settings window, go to Options > Properties.
3. Click on the Recording tab.
4. Check the checkbox next to “Sound Mix” (or “Wave Out” if you don’t see “Sound Mix”).
5. Uncheck the checkbox next to “Microphone.”

Record the JAWS Output

1. Now that you’ve set up the recording to use the internal sound mixer, launch your sound recording software.
2. Launch JAWS. (Note: for my sake, I usually began recording before I launched JAWS, just to be sure I captured everything and to avoid needing to restart JAWS once it started reading the Web page. It’s up to you how you want to handle it.)
3. When you’re ready to start recording JAWS’s output, go ahead and click “Record” in the sound recording software. When you’re done, click stop, save the file, and you’ll now have the output that lets you share how JAWS read the screen with others.

And better yet, you’ll have a referenceable file to replay if you get interrupted or can’t seem to repeat the same problem again! Have fun!

When you’re designing sites that sell services and products, especially health-related services and products, this question often comes up. Usually when it’s raised as a requirement, it’s followed by an awkward pause and silence. Those in the room would agree it’s important, as is accessibility in general. But in that pause and silence, you can see steam pouring out of designers’ and usability specialists’ heads, who are wondering, “How do we design for people with disabilities? What does that even entail? Can we handle that? And…what do we mean by cognitive disabilities?”

In our “Designing for Cognitive Disabilities” talk at the Usability Professionals’ Association International 2008 Conference in Baltimore, MD, Whitney Quesenbery, Sarah Swierenga, and I talked about what we’ve learned through the Telecommunications & Electronic and Information Technology Advisory Committee (
TEITAC, aka Section 508 and Section 255 refresh), from Dr. Clayton Lewis of the Coleman Institute, and from Sarah’s research at Michigan State University. The biggest discovery, which is not so shocking when you think about it, is that if you follow usability best practices – use consistency, use plain language, include landmarks, include ways for people to back up and correct mistakes… – you’ll be making great strides in making your site or application accessible by people with cognitive disabilities as well. (see below for our slides – our paper is available in the UPA 2008 proceedings (visit UPAssoc.org for more info))

I fell into the “wheels spinning, steam pouring, awkward silence” category when this topic came up in early conversations. I’ve worked with children and adults who have autism, Asperger Syndrome, Down Syndrome, cerebral palsy, and mental retardation. I have family members who’ve had various cognitive disabilities, including dyslexia, brain injuries, and mental retardation. And I was still at a loss – it’s hard to envision how to accommodate people without stopping to think about what they can do and what they do differently.

So here are some things to consider – these are not at all meant to oversimplify the field of cognitive disabilities – it’s really a complex and amazing topic. These items are meant to help you stop, think, and consider ways to improve on your existing site and product designs and accessibility, and, at the same time, improve usability for all your visitors.

Design Considerations

The following are based on our experiences working with users with various cognitive disabilities, as well as best practices that we’ve gathered from sites like Dyslexia.org, that focus on audiences with different disabilities.

All users

• Apply consistency in labeling, titles, navigation positions, etc. – match labels with the destination page’s heading so users know they clicked the right link.
• Include landmarks, to easily tell where you are
• Provide ways to back up if you make mistakes
• If your site automatically times users out after periods of inactivity, offer timer reset features – this will benefit users who take some additional time to process information or read through material
• Apply plain language guidelines!
• Offer spell check capabilities or suggestions for features like search engines or document generation

Users with dyslexia

Drawn from dyslexia.org

• Provide options to change background, foreground colors – high contrast like black on stark white can be challenging for these users to read. See dyslexia.org for examples. (Aside: my nephew has a much easier time reading things that are printed on green paper – the white paper was too busy for him)
• Use narrow columns, with 60-70 characters – easier to scan and read.
• Left justify content, as opposed to using full justification where left and right sides are even. Full justification creates varying white space that can cause problems.

Resources

• Designing for Cognitive Disabilities [PDF, 1.13 Mb], UPA Presentation by Walser, Quesenbery, and Swierenga
• The Coleman Institute
• Designing for Dyslexics, Accessites.org
• Telecommunications Problems and Design Strategies for People with Cognitive Disabilities, by Francik, Levine, Tremain
• Section 255, Telecommunications Act Accessibility Guidelines, specifically, 1194.31 (i)
• WebAIM, We Still Know Too Little, and We Do Even Less
• ACM CHI 2006 Workshop, Designing Technology for People with Cognitive Impairments