"Think aloud" is just as useful for testing accessibility--perhaps more. While screenreaders (for visually impaired users) do provide a cue to what users are reading, these devices don't provide information on whether it makes sense. "Think aloud" shouldn't imply "read aloud."

Specific examples where I found think aloud useful include:

1. Are the link titles clear? We found cases where meaningless text like "click here" tripped people up who don't have the benefit of seeing it in context with a visual design. In another test, an uninformative link triggered the download of a large PDF. The user was not aware that this occurred. As their browser blocked while the document downloaded, they told me their browser had crashed.

2. Is the information linearized logically? Consider a scoped search box, where you can search the site, a sub-site or a directory. In one example tested, when the search form was linearized users missed out on the scoping options. This is because those controls followed after the input button in the Document Object Model (DOM). Having them talk about what they could search for revealed this problem.

3. Is appropriate information given to help orient the user? When a user and I reviewed a university's site, she applauded how the page provided a hidden summary about what content was available but then remarked about how it could be written better.

4. Is the information usable? Thinking specifically about hearing impaired users, I found cases where video content did not not contain either a transcript or closed captioning.

Hope this helps.

I suggest having a look at the WebAIM (Web Accessibility in Mind) website's 'Introduction to Web Accessibility section' http://www.webaim.org/intro/#people.

It includes a collection of 'See also' links at the bottom that provide a wealth of information on specific disabilities including: * Visual * Hearing * Motor * Cognitive * Seizure

These specific disability types are further divided into subtypes, e.g. visual is divided into Blindness, Low Vision, Color-blindness. Each of those subtypes has its own section where you can find a list of key concepts that include a table of Challenges and Solutions for each disability subtypes-see example at http://www.webaim.org/articles/visual/blind.php#keyconcepts.

You could use the contents of such tables as a basis for compiling your list of methods for evaluating system usability for disabled groups that you trying to support.

Additional areas of the site not directly related to your task but that you may find useful:

• definitions of different disability types
• video overview of the difficulties users with disabilities face on the web
• guidelines for implementing web accessibility & principles of accessible design
• Constructing a POUR (Perceivable, Operable, Understandable, Robust) Website
• Design Considerations

Best of luck!

I know a method:

partial concurrent thinking aloud

Check it!

What's the system that you're evaluating?

Here are web design usability guidelines for people with disabilities from the NN/G. They're kind enough to make the report free! :) http://www.nngroup.com/reports/accessibility/

Some time just using people is the answer.

There are many great consultants specializing in their particular brand of accessibility because they live with it. In addition to your own methods and definitely when in final testing it's worth the money to use one of them.

They range from Glenda (known as The Left Thumb Blogger) http://www.doitmyselfblog.com/work-with-glenda/ to Jennison Asuncion (truly expert user who happens to be blind) http://www.linkedin.com/in/jennison.

The World Wide Web Consortium recently published two documents on involving people with disabilities at the beginning of development, during user testing, straight through to accessibility evaluation which may be of assistance http://u.nu/6kb74 - As a screen reader user myself, I too see value in some form of "Think Aloud" type of inquiry. If sound is an issue, have the screen reader user wear a headset.

Keep in mind that when conducting user testing with people with disabilities who require either adaptive hardware (e.g., an adapted mouse) or adaptive software (e.g., software that speaks what is on the screen) when interacting with a web page, you will need to factor in their level of knowledge on the use of these technologies in addition to their experience using the web in analyzing results. The last thing one would want is a situation where something has been built to be usable and accessible, however the fact that a user does not know how to leverage their adaptive technology or has limited experience using the web means that they may deem the page to be inaccessible or unusable. This will become more apparent as we move toward increasing adoption of rich internet applications because the way in which certain adaptive technologies interact with RIAs presents a different user experience than what is expected when interacting with a page built using plane HTML.

One final "complication" - different browsers and even browser versions, combined with certain adaptive technologies and again, different versions, may provide different user experiences and results. It is important during testing therefore to be clear in documenting: platform, browser (and version) and adaptive technology (and version).

While I've focused on the web, much of this applies to software testing as well, minus the browser issues.

Hope this has been of help.

I think this is what you are looking for: http://www.theuxbookmark.com/2009/08/usability-engineering/evaluating-for-accessibility

"It provides guidance on incorporating accessibility into common evaluation methods, including standards review, heuristic evaluation, design walkthroughs, and informal evaluation with users with disabilities. The Usability Testing section is an overview of usability testing with participants with disabilities."

Hope this helps.