User research that’s truly inclusive (even when the tools aren’t)
How to include all users — of all abilities — in digital service design, when almost all of the user research tools we’ve tried are inaccessible to so many users?
Below I’ve listed some practical tips we’ve learned for including users of all abilities throughout design and delivery (not just as an accessibility afterthought bolted on at the end).
In doing this, we found we had more to gain than we expected: By including users with a range of disabilities and users with low digital skills, throughout the design and iterative delivery, we came to believe that we created better (simpler, smarter) services for all users of all abilities.
Special thanks to all of our clients who’ve warmly embraced inclusive design — most especially those at HMRC on a soon-to-be-released GOV.UK communications site, and at Jewish Care — where Sandi Wassmer was a source of wisdom on inclusive design.
Tips and learnings for inclusive user research
Creating a site map, naming (Information Architecture — IA)
- The otherwise excellent OptimalSort is not terribly accessible
- We found old school physical cards work best for many users with disabilities, or with limited digital skills
- Bigger cards (e.g. A5), with big text (ideally printed on big labels), and a smaller number of cards than usual (perhaps 30 at most) all help
- It’s often helpful to have a carer or user researcher reading aloud, or physically moving cards, for users for whom this is difficult or impossible
Navigation and IA validation
- Treejack is a great tool for testing and refining site maps. But it too is not very accessible, for many users
- So we used it in person with carers / our researcher making selections in line with users’ decisions and / or reading the options to them at each stage. But this does limit the quantity of responses, which is otherwise a strength of Treejack.
Wireframing and early prototyping / observational testing
- ‘Paper’ wireframes and other drawings, for instance created in Balsamiq, are obviously not accessible to most people with a visual impairment
- For clickable prototypes, Axure output has poor accessibility e.g. for voice and other assistive technologies (ATs), so this was not an option
- We tried having our user researcher ‘audio describing’ wireframes to visually impaired users for their input, with mixed results
- More successfully: we moved to in-browser design and prototyping very early on — almost from the very start. And we ensured these clickable wireframes and prototypes were standards compliant, and with WAI ARIA mark-up. This was significantly more effort than knocking out simple clickable wireframes in Axure, more even than creating non-compliant code prototypes — but it meant prototype research and testing worked with users’ AT, voice, touch, etc. And in the longer term the prototype code was, where still relevant, a big step towards the code for the live site.
Remote research and testing
- Most ‘screen share’ tools for remote testing which we’ve used in the past (such as join.me) don’t work well with voice or other AT
- We did however find one which worked with at least one voice reader — Teamviewer was a good solution for remote testing with JAWS.
Online surveys
Surveys are the bread and butter of quantitiative user research.
We did some accessibility checking on four survey tools and Alistair Duggin at GDS did so on eight. Between us, we didn’t find a single really accessible survey tool. Many (including SurveyMoney and Survey Gizmo) talk up being accessible on their sites but fail to live up to it. (Other survey apps which also aren’t good on accessibility: Bristol Online Survey, Client Heartbeat, Google Forms, Smart Survey, Survey Planet, Typeform, Zoho Survey)
Help! Do you know of a survey tool which is accessible?
Some general lessons
- Where possible, we perform our observational research / testing in person using people’s own adapted systems (i.e. the users’ tablets, phones and PCs). Almost every AT system is different, or at least differently set up, and we found that actual systems adapted and in use by our users provided the most valuable research insights — not least as we could focus on the research rather than users coming to terms with a different environment.
- We also found that we needed to be mindful of the ‘load’ on people for whom interaction of any sort is difficult, tiring or taxing (and that includes being ready to end the session at any point). In general it means keeping sessions as short as possible.
JCi: A micro case study of inclusive design helping everyone
We found that users with impaired memory or cognition found that all of our ideas and options for the JCI site’s main section names were confusing. In the end, after several rounds of research and iteration, we found that clarity was more important than brevity. And we hit on the idea of having section names which are (unusually) long but with part of the name picked out for more concise reference (for instance “CARE WHERE you’re living or staying”). As is so often the case, we found this tested better with all users of every ability. Likewise, following inclusive research, the Directory search filters were simplified — which has benefited everyone.
I’d love to learn more, and share
First of all, have I got any of this wrong? Perhaps some of the tools I’ve mentioned can be made accessible — or you know of other tools which are.
And please do share your experience on this, as I’d love to build up a catalogue of accessible user research tools, methods and tips — to share.
Acknowledgements
Thanks to several colleagues at BV who helped me assemble this list of ideas and tips, very especially Kim Range — who did most of the research this is based on, and who is my ‘go to’ for questions on this (and a lot else).
