You just found out your application or website needs to be accessible and are handed a set of Section 508 standards. Where do you start? After the question came up on the IXDA discussion list recently, I realized it still seems like a scary prospect for people new to accessibility. So hopefully this will help.

Validate

It’s not a Section 508 standard, but before you do anything else, validate your code. Why? Because when assistive technologies are looking through code and trying to translate that into spoken text, Braille displays, etc., they’re trying to figure out what’s what. If you have unclosed tags, improperly nested tags, etc. they don’t know what’s what and choke. Take a listen to some bad code with JAWS (popular screen reader) – you won’t know what hit you.

There are free tools out there like the W3C Validator tool (http://validator.w3.org) and many IDEs like Dreamweaver have built in validation options. It can take a few minutes per site or page, depending on what type of site you have (content or application), and it will make a huge difference.

Content Sites

If your site contains content, which even web-based applications will, look at it in this way:

• Navigation / links – can you reach all navigation (including nav bar menus) via the keyboard? if not, do you have landing pages that can be reached by keyboard as alternative to mouseover menus?
• Text – if you use images for headings, nav links, etc. do you have alt attribute or text behind it (and is your image still readable when zoomed in?)
• Headings – are they identified via <h1>, <h2>, etc.? That helps people jump to different parts of the document and bypass nav menus
• Tables of data – do you have table headers identified with <th> (CSS classes like “heading” etc. aren’t enough)
• CSS for general site and content layout, not a table-based layout - and following on tables, imagine hearing there are 10 tables on a page? or checking to see if your tables are used for data and need <th> tags? If the web standards mavens haven’t convinced you to go with CSS, run your page through Fangs (mentioned below) or JAWS and maybe that will convince you! “3 tables…table with 1 column and 20 rows…table with 3 columns and 18 rows” (and nothing contains any data worthy of a table! ugh)
• Search, contact fields – when you have form elements, do you use label tags or title attribute to provide labels? (preferrably visible onscreen to help all visitors) if you have drop-down menus, can users select from them and then select the action (e.g., select a category, then click Go; vs. automatically moving to another place as they select)
• Unique labels for documents – if you have PDFs and other doc lists, are the links or icons labeled with unique on-screen text (preferrably) or title attribute (so someone using screen reader doesn’t har “PDF PDF PDF” etc.)

Web-based Applications

If the site’s a web-based app, forms and tables for presenting record/data collections are usually more of the beast. You’ll want to check items above, and then really go deep into the forms, checking that:

• <label> tags are used, preferrably explicitly (e.g., <label for=”idforfield”>labelname</label><input id=”idforfield”>…
• <fieldset> and <legend> are used with groupings of related fields (e.g., multiple parts to an address block, phone numbers with extensions, etc.)
• Error messages and feedback can be communicated to users, possibly via <span> tags within the <label> tags (set span to hidden when there’s no error message, and then set to visible when there’s an error so it’s picked up by assistive technology)
• Any data-dependent items (e.g., lists refresh based on selection)? is the change downstream?
• You’ve used CSS for laying out forms, rather than using a table-driven layout
• If you’re using AJAX and other RIA components, and want to know about ARIA, well, that can cover several posts or a full-day tutorial! (talk to me)

There’s more (e.g., image maps, frames, etc.), but the above covers most of the usual problems.

Favorite Plugins & Tools

Firefox is great if you have the flexibility to use it for checking pages. Here’s a list of my favorite plugins…

• Web Developer Toolbar (https://addons.mozilla.org/firefox/addon/60) – great for displaying information about various fields, content, etc. so you can see if heading tags, labels, etc. are missing
• Firebug (https://addons.mozilla.org/en-US/firefox/addon/1843) – one of the greatest tools ever, lets you inspect elements on a page and figure out what’s happening. So handy when used with JAWS and other screen readers / tools as you’re checking.
• Fangs, a screen reader emulator – it’s not a perfect emulation, but does give you an idea (https://addons.mozilla.org/en-US/firefox/addon/402)

The Opera browser’s great for checking accessibility too.

If you’re using IE, you can install the Web Developer Toolbar that’s useful. Jim Thatcher has some great favelets as well to help tweak the Web Developer toolbar.

Hope it helps. This may seem overwhelming – once you run through it once or twice, you become familiar with what to check.

For what it’s worth, the automated tools can help spot items to check, but you’re better off with a good approach and plugins for Firefox / IE to check things. The automated tools can give some false positives and negatives that could be pretty critical. I’ve seen organizations get excited when the tools give a green light (despite major accessibility flaws, especially where forms are concerned), and concerned customers when the report shows all the “warnings” for elements that needed manual checks. And the times, they are a-changing, so the techniques that were givens 5 years ago aren’t the only way to provide information to users anymore.

Delicious Resources

If you’re brave, check out my Delicious bookmarks on Section 508 and accessibility – I’ve bookmarked a bunch of tools and articles I’ve found over the years at http://delicious.com/walserk/accessibility.

The Usability Professionals’ Association (UPA) and Knowbility have teamed up to create a curriculum and training program designed to enhance usability practitioners’ knowledge and understanding of accessibility standards and what constitutes an accessible product. The first offering will be at Access U in Austin, Texas, on May 11-12, 2009.

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).

If you run through Web sites with screen readers like JAWS, the steps below that describe how to record JAWS output could save you time.

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!

More people are wondering – “How do we design for people with cognitive disabilities?”

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