Iterating a form wizard | from research to design
•Download as PPTX, PDF•
1 like•948 views
A lightning talk for Global Accessibility Awareness Day 2019 #A11yMelb on accessibility improvements to a registration form wizard.
Recommended
Recommended
More Related Content
Similar to Iterating a form wizard | from research to design
Similar to Iterating a form wizard | from research to design (20)
More from Vernon Fowler
More from Vernon Fowler (14)
Recently uploaded
Recently uploaded (20)
Iterating a form wizard | from research to design
- 1. From research to design Iterating a form wizard @vfowler
- 2. Outline •Form wizard designs •Manual testing & issues identified •Addressed issues •Next steps
- 3. Form wizard designs Onsite kiosks Other devices
- 4. Manual accessibility testing scenarios 1. Laptop + Firefox + JAWS → email 2. iPhone + Safari + VoiceOver → SMS
- 5. 7 issues identified •Validation errors imperceptible •Mismatch to user’s mental model •Spinners on postcode input •<article> tag •Driver’s licence as proof of address •<label> lacks a phone format example •Link to a modal
- 7. <button>s weren’t matching Automated testing won’t pick up on this. Photo by Adeolu Eletu on Unsplash
- 9. Mismatch to user’s mental model
- 10. Radio buttons, fieldset & legend
- 11. Spinners on postcode input type=“number” → type=“text” pattern=“[0-9]*” When to use the number input by Adam Silver
- 12. Photo by Matthew Guay on Unsplash <article> on a form Confusing.
- 13. Driver’s licence Ineligible. Photo by Laura Gariglio on Unsplash
- 14. Next steps Photo by Ant Rozetsky on Unsplash • Require WCAG 2.1 AA up front. • Align with Australian Government Design System. • Test with low-vision and mobile users.
- 15. Thank you Comments & questions? @vfowler
Editor's Notes
- Hi everyone. First, I want to thank Jamie Kelly. He 1st tested our registration form wizard in September last year. Pictured here in our follow-up validation testing in February, he’s sitting at a table with his laptop open and an external keyboard. Jamie is blind, has a great sense of humour, and makes an excellent participant with amazing think-out-loud skills. Second, I want to thank Troy Rasiah, our brilliant developer and database guru, collaborating with me throughout this project. Over 5 months, we made 7 iterations, and resolved 5 of the 7 issues identified from Jamie’s initial session.
- I’d like to share some of the improvements we made. Today I’ll cover … Our form wizard designs; Manual accessibility testing & the issues identified; How we addressed some of the issues; And I’ll finish with next steps for a better future.
- We actually have 2 form wizard designs: One for these onsite kiosks which are attached to cabinetry. – The onsite kiosks aren’t intended for screen reader use. Branching from that is a design for all other devices (my photo here shows Jamie operating this form on his iPhone via a Bluetooth keyboard). – It’s this design for other devices that we’ve been testing and iterating.
- Our manual accessibility testing consisted of 1 task, to become a member, with 2 scenarios: In scenario 1: using a laptop, Firefox, JAWS, and email to receive membership. In scenario 2: using an iPhone, Safari, VoiceOver, and SMS to receive membership.
- From the September test, we identified 7 issues. In order of severity, they are: Validation errors imperceptible to screen readers; A mismatch from our conceptual model to the user’s mental model; Spinners on postcode input; An <article> tag announced on every step of the form; A driver’s licence was the only example of a document members can use to prove their address; A <label> lacking a format example; A link to a modal. I’ll describe the first 2 or 3 issues, and how we approached them. If you’re interested in hearing about the remaining issues, let’s chat afterward.
- Imperceptible validation is a show stopper. On his laptop at step 1 of the form, Jamie gave both a mobile number & email address. After pressing Next, validation errors are displayed in red text on the page but the screen reader is silent. We need the screen reader to announce the validation, so we: Inserted the error text within the <label>; Set the focus to the 1st input with an error. This required updating the jQuery framework that handles validation.
- A mismatch of conceptual model to user’s mental models won’t be picked up in any automated testing. A pattern we had used in our form wizard was a few <button> elements for users to indicate a choice and to take them to the logical next step. It appears neat & efficient – it works on our kiosks. It has perfectly valid mark-up. Let’s see how this fell apart in our testing session.
- Wizard step 2 asks users to choose their preferred contact for membership delivery. A screen reader announces: “We’ll send your library membership details to your preferred contact”, followed by 2 <button> elements. To demonstrate the confusion that our interface was causing, I’ll play 20 seconds of video from the test session. [Play video] The last thing Jamie commented was: “I would have thought neither would be selected and you’d have to select one.”
- <button> elements make sense for kiosk design, but through a screen reader the final words “…select button” exacerbates the confusion. Even if we accessibly hid the word SELECT, we still had the conceptual model of <button> elements: a mismatch to our user’s mental model. To address this, we had to replace the buttons.
- Switching to radio inputs, and adding an explicit Next button was the easy bit. The hard bit was making the choice of options mandatory in an accessible way. Thanks to Russ Weakley & Allison Ravenhall who contributed to our solution: using aria-describedby to have both a hint and validation message associated with the <fieldset>. When Jamie tested this in February, it perfectly matched his mental model.
- Our old form design used input type=“number” for entering an Australian postcode. This makes it easy for Android and iOS but on desktop devices, it presents spinbox controls. Visual users might ignore these stepper buttons, but it confused our participant and exploded the time it took to complete this field. Adam Silver wrote a blog post explaining the most inclusive way to capture numeric codes is to use an input type=“text” with a pattern=“[0-9]*” attribute. This removed the spinners both visually and to screen readers, and some smartphones will render a chunky number-pad for easy entry.
- An <article> tag was left over from an initial page template. Screen readers announce “article”. That’s just confusing on a form. We removed it from the templates.
- To obtain an additional member privilege, we need proof that you live in Victoria. The only example document we listed was a driver’s licence. Blind people are ineligible for such things. Although we’ve added utility bill as a second example, this doesn’t really resolve the issue for Jamie who pays his bills electronically. Our alternative of receiving a letter by mail also relies on a third party. By adding a second example, we’ve resolved this issue, but not yet for everyone.
- To lessen the remediation effort in future, and have better designs out of the box, some next steps I’m taking include: WCAG 2.1 AA as a requirement up front; Explore how might we align form interfaces with the Australian Government Design System; Test with low-vision and mobile users.
- Thank you for listening to my talk.