Accessibility testing a multi-channel form wizard

Editor's Notes

1. Hi everyone. I helped iterate the Become a Library member form a couple of times this year. Our latest iteration “lever[s] existing technology [we previously didn’t] use” – you now confirm that you’re you by email or SMS. Growing complexities also meant converting a single page form into a multistep wizard. I’d like to share some of what we learned from accessibility user testing our new onboarding flow.
2. First, scaling up to a form wizard; then failing at validation; winning at progress; and breaking mental models. I’ll finish with a note on logging and iteration.
3. Until last Tuesday we had a simple one page form that many people completed on this computer. They received a plastic card and became a Library member. Members signed up several times: they’d lost their card, forgot they’d already joined, their renewal email went to an old address, and so on. It was also easy for spam bots to submit the form multiple times.
4. Our project aims: ditch the plastic, minimize delays in providing member benefits, maximize self service, and annihilate those wasteful spam registrations. Oh, and while you’re at it, [Click] make the form work in these kiosks too!
5. To achieve these, we employed a form wizard: a “design pattern to simplify complex processes performed infrequently or by novice users.” Ideally people would join only once in their life, and we’re all novices the first time, right?
6. Our participant tested our wizard, first with their laptop. Fail at step 1: Injected validation messages weren’t announced by the screen reader. Even if they could, our message doesn’t indicate what’s wrong with the input, nor how to fix it. [Click]  Show stopper! I had to assist with error recovery… Next.
7. It’s vital to show your progress, to “Distinguish the current step, and how many steps there are left.” We need to provide a sense of progress to screen reader users too. [Click] Unfortunately the HTML5 progress bar is not accessible!
8. Scott O'Hara suggests “treat[ing] the progress bar as a visual decoration, hide it from screen readers, and provide visually hidden text as a means to consistently convey the information.” (Extra: His testing found that a “progress bar won't be fully accessible in all screen reader and browser pairings”.)
9. To provide visually hidden text, we use the screen reader only class from the Bootstrap framework. [Click]  Our participant heard and understood they were making progress.  Let’s take a look at buttons…
10. These buttons completely baffled our participant. We’d been so focused on making easy interactions with large touch targets for our new kiosk devices, that we lost sight of underlying semantics.
11. Our participant pointed out that the buttons really should be radio inputs, and, unlike previously, this step lacks an explicit Next button. The interface didn’t align with their mental models of interfaces or flow! [Click] We’d chosen interface elements … poorly.
12. 3 days before our testing session, Hui Jing Chen posted an inclusive design solution that makes radio inputs work for screen reader and touch screen users alike. For our next iteration of the form wizard, we’ll be working on fixing form semantics and the validation issues.
13. Lastly, I recommend Eric Bailey’s advice: log issues you’ve identified, rate them, and prioritise which ones to iterate in your upcoming sprints.
14. Thank you for listening to my first ever lightning talk.