At the Involving People with Disabilities in User Experience Research webinar, hosted by UserTesting.com, Sarah Horton shared insights learned from including people with disabilities in her user research.
She outlined what designers and developers can do to design accessible user experiences on the web.
Sarah, the co-author of A Web for Everyone with Whitney Quesenbery, is the director of accessible user experience and design at The Paciello Group.
I know about Sarah from her Web Style Guide, one of the first guides I read when I began working on the web in 1997.
What I enjoyed from the webinar: the tips on recruiting people with disabilities and the reinforcement for layout and coding practices (not placing focus on an input field) I’ve been using.
Here are my notes from the webinar.
Recruiting and Including People with Disabilities in Usability Studies
- Partner with advocacy and support organizations to tap into their members
- Have people with disabilities use their own device, they customize their own settings
- Send documents in advance
- Have a doggy bed available for service dogs
- Video recording provides the most accurate representation of a test. Mobile testing is hard to do for people with visual disabilities. They will hold the phone very near their face. Suggestion: Connect the phone to the display monitor and record the device, person, and display monitor
10 Design Insights for Accessibility
- Consistent control locations help non-visual touchscreen users. There are common locations for controls. Making design adjustments to improve the experience for people with disabilities will likely improve the experience for everyone.
- Complex tables are difficult to track, especially when magnified.
- Print matters, too. The printed version should support large print.
- Critical information should not be on the right side or the screen. Web content on the right disappears when users zoom in. Think about location of critical info or go responsive.
- Setting focus is disorienting for everyone, even more so for people using screen magnifiers. The problem is when cursor focus is set programmatically on the input field. For screen readers, the page will scroll to the input field, but you have to scroll to find out what’s going on. Many websites reset focus, but it’s not a good practice.
- Overlays and dialogs can be difficult to distinguish when magnified. You can’t tell if you’re on a page or on a popup. Everything is the same color, there’s no depth to the popup.
- Text entry is more difficult than selecting from a predefined values or list of choices. Example: Massachusetts Bay Transportation Authority trip planner. There’s no autocomplete; you have to spell the words correctly. An autocomplete feature or select option would be easier than typing into a field. However, in mobile testing with Siri, it’s easy to use and can be used to fill in a field.
- Swipe gestures don’t work consistently with VoiceOver. Have a backup for any type of interface that you build with swipe.
- Layouts with visually grouped elements work well when magnified. Test contrast against background color.
- Slow loading pages impact accessibility. Pages that take a long time to load cause issues with screen readers and screen magnifiers. The screen reader doesn’t give feedback on what’s happening on the page until the entire screen is rendered. There is a lag effect when you click a link on a page because the screen reader is still loading the current page. Example: CNN home page.
Update March 13, 2014: Sarah graciously published her slides from the webinar on Slideshare.
