Ideas 2005: Technology Showcase for Accessibility

Ideas (Interagency Disability Educational Awareness Showcase) is an annual expo held in Washington D.C. for federal employees and contractors. Leaders from government agencies and non-governmental organizations present talks, and there is a technology showcase for software.

The expo’s focus is on:

• Making the government’s workplace more accessible to its employees with disabilities (hardware, software, physical environment, emergency preparedness, etc).
• Making the government’s Web sites  more accessible to the general public.

The federal government has issued regulations to ensure that workplaces and Web sites are accessible (see Access-board.gov). But, as many conference speakers repeated, the government agencies’ ultimate mission is to make information technology accessible to all the people that need it – not just follow the letter of the law.

Brook Group attended several sessions including:

• Web/E&IT Accessibility Testing and Methodologies
• Section 508 Standards: Back to Basics
  (Section 508 is the government’s guidelines for accessible Web sites)
• Accessible E-Learning
• Older Wiser Wired: Working to Bridge the Digital Divide

Common themes

Government agencies often out-source their work to outside vendors, but don’t do due-diligence. They often neglect to include compliance with accessibility guidelines in their RFPs. Also, many vendors, when asked, will claim their product is compliant – they tell the procurement officer what they want to hear, even if they've never heard of the guidelines.

Some federal agencies have large in-house accessibility-focused departments, with specialists and testing labs. These departments will often work together with vendors, to make accessibility improvements to their products and to test it – a win-win situation for both parties. Smaller agencies with limited resources are not so fortunate. There is a movement afoot to share information and resources across agencies, but it still has a way to go.

Sometimes, an agency may spend a lot of time doing an accessibility audit of their Web site or software, but then doesn’t follow up.   They don’t make the recommended improvements – the follow-up just does not happen.

There were discussions about the trade-offs between accessibility and time/resources.
For example:

• Some software may solve all your problems, but it has an accessibility issue. Do you still acquire the software?
• Sometimes, if you were to make something “accessible” it would not longer fulfill its mission. For example, labels that need to appear on small gadgets. Larger, more readable labels simply won’t fit.
• Users might need drag-and-drop features and extra visuals, but then you have to provide alternatives for disabled users – can you afford to spend the time?

No clear consensus emerged, for how to deal with these issues.

Testing tools and methodologies

This session included Section 508 representatives from the government and outside vendors that provide services and software tools, for testing the accessibility of Web sites and software.

Testing tools are helpful – they bring consistency and repeatability to the testing process; they allow you to test huge quantities of pages efficiently; they allow you to test at various steps throughout the product development lifecycle.

The downside is that they can exhibit false positives and false negatives, and they can’t test interactivity very well. So you need to evaluate the results, and human testers are also needed.

Someone suggested that, just as Web developers test their sites in various browsers/platforms, they should test it in various assistive technologies. The problem is: there are thousands of tools; each tool has various versions; time and resources are limited; you don’t have time to become familiar with how the tools work.

The general “modus operandi” seems to be: if you get a complaint from someone who cannot access something with certain software, then try to fix it or provide the information in an alternative format.

Ideally, you wouldn’t just test your product to make sure it works in assistive technologies. You’d also test it with disabled users. This really is usability testing – you are testing a subset of the user base that happens to be disabled. You’ll need to sift through the results – is someone having a problem because your product isn’t usable, or maybe they haven’t mastered their assistive technology, or maybe their tool has a bug, etc.  Unlike automated testing tools, you can’t afford to do this kind of testing at multiple points in the development lifecycle.

Making sites more usable for seniors

American Association of Retired Persons  (AARP) presented the results of recent research.

1. A checklist for Web sites

Based on research into what makes sites work well for seniors, AARP has developed a list of heuristics – rules of thumb to follow when designing sites. If you take a look at this list, you’ll see that these are common-sense tips that make the Web more usable for everyone, not just seniors. The proportion of disabled users is larger in the senior population, but there’s really nothing unique about this population’s needs.

2. “Channeling” as a method for usability testing

They presented an approach for doing usability testing inexpensively – useful for government agencies with limited budgets and resources. It involves developing thorough user profiles (“personas”) for fictional people that are representative of your audience. Then pretend to be them – “channel” them as you browse through a Web site, doing the types of tasks they would be interested in. Jot down notes about things that are difficult to understand or navigate.