QA testing with assistive technologies

Colin Clark colinbdclark at
Fri Oct 7 22:00:27 UTC 2011

Hi Heidi,

This is a really great question, and something we've chatted a bit about in the past without coming up with a formal policy. Some thoughts below...

On 2011-10-07, at 12:27 PM, Valles, Heidi wrote:
> I was chatting with Justin this morning in the IRC channel about how we're not currently including AT testing in our QA test plans. I think it's important when we are releasing software with accessibility as a main focus to have more of a formal process for checking out how things do with assistive devices. 

I agree, we should definitely start to establish a baseline profile for testing each component using assistive technologies, and we should ensure that it's a central part of our quality assurance process.

> Luckily, many assistive technologies either work through the keyboard or emulate keyboard functionality and keyboard testing IS included in our QA process, so we are in a good position to assume many ATs will work well with our components. Also I think most of us check things over with screen readers in the development phase of components but I'd like to see more of a final/formal test before releases. Thoughts?

It think it's really important to expand our thinking of assistive technologies beyond just the screen reader. While screen readers are interesting and challenging tools to support, they're only one of many solutions used by our users. It would be great to increase our test coverage with a diverse selection of tools: screen magnifiers, onscreen keyboards, and more. 

There's also the need to support alternatives to assistive technologies: flexible layouts and screen sizes in particular.

We are an open source community driven by participation, so we need to consider how we can leverage that and include as many people as possible without requiring them to spend a lot of money on proprietary technologies.

> The tricky part is figuring out which ATs to test - we don't want to be prescriptive or limiting. But I think we should still get some testing in regardless - can we check over our components with the most recent version of some of the more popular ATs? I could see this exercise being... fun, informative, educational, interesting, helpful!

Yes, it really would be fun! Heidi, I'm wondering if you'd be willing to take on the work of drafting a proposal for quality assurance testing of Infusion with assistive technologies? I'd like to see us take a layered approach:

1. Establishing a baseline for required testing across all QA plans, which will include coverage of the following features:
	a. Keyboard navigability (I think we do a decent job of this already)
	b. Display flexibility: the ability for our components to scale to different screen sizes, resolutions, and magnifications
	c. Support for a core open source assistive technology: to start, perhaps NVDA and Firefox

2. Suggest a toolkit of a diverse set of technology with which the Fluid community is encouraged to test Infusion and contribute fixes to support. This could include a mix of popular commercial and open source assistive technologies, and reflect the many ways people access our user interfaces. I can imagine it would include some readily available screen magnifiers and onscreen keyboards.

Some of our UX walkthroughs in the Design Handbook might help with this. They're a little dated, but might provide us with some inspiration:

> Our QA process will also likely soon expand to include devices other than desktop: mobile, tablets, etc. How will we make decisions around which devices to test on? Perhaps that's a whole other can of worms, but possibly related.

I think think our best technique for this is to leverage our open community, ensuring people who have a stake in the support of a particular device or assistive technology can easily contribute QA testing and bug fixes. Our openness to help mentor newcomers to the testing process, as well as openly accepting and assisting with patches and fixes, will help ensure that Infusion continues to reflect the value of diversity that is it our core as a community.



Colin Clark
Technical Lead, Fluid Project

More information about the fluid-work mailing list