Accessibility testing a multi-channel form wizard
•Transferir como PPTX, PDF•
1 gostou•1,361 visualizações
A lightning talk on lessons learnt from our pre-launch test of a multi-channel form wizard. See https://twitter.com/vfowler/status/1044468802786922497 for links to references cited. Part of World Interaction Design Day #IxDD for @a11ymelb meetup (Melbourne Web Accessibility and Inclusive Design).
Recomendados
Recomendados
Mais conteúdo relacionado
Mais de Vernon Fowler
Último
Último (20)
Accessibility testing a multi-channel form wizard
- 1. 25 September 2018 Accessibility testing a multi-channel form wizard Vernon Fowler @vfowler Photo by Buzz Andersen on Unsplash
- 2. Agenda 1 2 3 4 5 Form wizard Validation imperceptible Progress for all Buttons ≠ mental model of radio inputs Log issues & iterate
- 3. The form before … https://www.instagram.com/p/Bn3a2c3nl5q/ by Vernon Fowler on September 18, 2018
- 4. Before wizardry https://www.instagram.com/p/Bn7A3BSDdDh/ by Vernon Fowler on September 20, 2018
- 5. Wizards: Definition and Design Recommendations by Raluca Budiu on June 25, 2017 https://www.nngroup.com/articles/wizards/ Bring in the form wizard “a powerful design pattern … to simplify complex processes performed infrequently or by novice users.”
- 6. Validation imperceptible Error Messages: Designing for Error — Part 3 by Krisztina Szerovay on September 18, 2018 https://uxknowledgebase.com/error-messages-designing-for-error-part-3-8bfb547f9246
- 7. Visible progress steps Wizard Design Pattern by Nick Babich on April 8, 2017 https://uxplanet.org/wizard-design-pattern-8c86e14f2a38
- 8. Styled Progress Bar by Scott O'Hara on July 28, 2018 https://scottaohara.github.io/a11y_styled_form_controls/src/progress-bar/ Perceivable progress “treat 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.”
- 9. Perceivable progress Screenreaders · Bootstrap https://getbootstrap.com/docs/4.1/utilities/screenreaders/
- 10. Buttons?
- 11. <button type=“submit” name=“confirm” value=“sms”> <button type=“submit” name=“confirm” value=“email”> Buttons ≠ mental model of radio inputs https://gph.is/1ea79Xa
- 12. Inclusive design for radio inputs Customise radio buttons without compromising accessibility by Hui Jing Chen on September 3, 2018 https://www.chenhuijing.com/blog/customise-radios-without-compromising-accessibility/
- 13. Log issues & iterate The Importance Of Manual Accessibility Testing by Eric Bailey on September 12, 2018 https://www.smashingmagazine.com/2018/09/importance-manual-accessibility-testing/
- 14. Thank you. Comments & questions? @vfowler
Notas do Editor
- 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.
- 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.
- 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.
- 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!
- 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?
- 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.
- 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!
- 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”.)
- 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…
- 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.
- 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.
- 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.
- Lastly, I recommend Eric Bailey’s advice: log issues you’ve identified, rate them, and prioritise which ones to iterate in your upcoming sprints.
- Thank you for listening to my first ever lightning talk.