QA testing with assistive technologies
obara.justin at gmail.com
Tue Oct 11 15:06:50 UTC 2011
I'd like to start by saying thanks to Heidi for starting this thread. It is a very important topic for us to discuss.
I think we should begin by looking at what we do now. Fluid Infusion currently takes the lead from Yahoo's A-grade browser support when determining which configurations to test against for a given release. What's nice about following Yahoo's A-grade support, is that we have a reliable source who has access to a broad variety of users and is able to monitor their traffic. We unfortunately, as of yet, do not have detailed metrics of our user base to glean this information from.
YUI a-grade: http://yuilibrary.com/yui/docs/tutorials/gbs/
Infusion Browser Support: http://wiki.fluidproject.org/display/fluid/Prior+Browser+Support
A while back, I had started investigating what it would mean to put together a similar chart for screen readers ( http://wiki.fluidproject.org/display/fluid/Screen+Reader+Support ). There were several problems with this.
AT's span well beyond screen readers, we didn't want to limit ourselves to supporting a single type of AT
We didn't and may still not have a good source for determining which AT's should be on our support list.
We didn't want to be prescriptive of what AT's should be supported
What we have done instead is to attempt to implicitly incorporate as much of the typical interaction requirements as possible into the test plans. This is most evident in the keyboard navigation sections of the test plans. I believe that having these types of requirements built in, and not tacked on or separate, is the best way to have them tested all the time. A while back, Alison and Armin put in time to try to incorporate the WCAG 2.0 guidelines into the test plans. While the first pass has fallen out of date with the canonical test plans, the format and structure are very close to what's needed. I believe that with a little bit of work, we can have these integrated back into the canonical test plans.
example test plan: http://wiki.fluidproject.org/display/fluid/Uploader+QA+Test+Plan
example test plan with wcag: http://wiki.fluidproject.org/display/fluid/Uploader+QA+test+plan+with+WCAG
Heidi has brought up a good point, that while trying not to be prescriptive we may have gone too far the other way. One of the common misconceptions about the Testing Tasks and browser support is that it is all that we cover. However, it is really just the base that we ensure. That being said, it has not been well communicated that we should be doing AT testing of some sort as well. While we do incorporate AT testing along with our development, it would be good to formalize this, to ensure that we are getting the coverage we actually want/need.
Heidi I'm looking forward to seeing your draft proposal, I think you'll have some great ideas to put forward.
Joshue, it was really great to see your e-mail. Colin is correct, we really need the support of our community. Also, it's always great to have real users let us know what they think, both from a functional and usability aspect.
On 2011-10-08, at 4:41 AM, Joshue O Connor wrote:
> Hi all,
> I would like to help with some of the testing, while I don't have tons of time to devote to it - I could make some contribution as I would like to support the Fluid project as it is one of the most advanced in terms of supporting the needs of people with disabilities. I run a usability lab and do a lot of user testing involving people with disabilities in the Centre For Inclusive Technology, in Dublin Ireland, and I could drum up a few of my nerdy blind friends to informally test some of the components etc.
> Please feel free to discuss this more on list or ping me off list.
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work