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:
http://wiki.fluidproject.org/display/fluid/Simple+Accessibility+Review+Protocol
http://wiki.fluidproject.org/display/fluid/Comprehensive+Accessibility+Review+Protocol+for+PC
> 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.
Thoughts?
Colin
---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
