Below is a written version of my lightning talk given at the A11y Bytes event in Melbourne on Global Accessibility Awareness Day, 16 May 2019. This follow-up lightning talk demonstrates how we overcame technical and non-technical issues to make a member registration process more inclusive.
In September 2018, manual accessibility testing revealed significant barriers to completing a high demand multi-step form. I thank Jamie Kelly, who first tested our registration form wizard in September last year. Pictured below in our follow-up validation testing in February 2019, 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 tester with amazing think-out-loud skills.
I also thank Troy Rasiah, our brilliant developer and database guru, collaborating with me throughout this project. Over five months, we made seven iterations, and resolved 5 of the 7 issues identified from Jamie’s initial session.
- Form wizard designs
- Manual accessibility testing scenarios
- Issues identified
- How we addressed (some) issues
- Next steps
Form wizard designs
We actually have two form wizard designs:
- One design for onsite kiosks 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.
Manual accessibility testing scenarios
Our testing consisted of one task, to become a member, with two scenarios:
- Using a laptop, Firefox, JAWS, and email to receive membership.
- Using an iPhone, Safari, VoiceOver, and SMS to receive membership.
Seven issues identified
We identified seven issues. In order of severity, they are:
- Imperceptible validation errors;
- A mismatch from our conceptual model to the user’s mental model;
- Spinners on postcode input;
<article>tag announced on every step of the
- A driver’s licence was the only example document as proof of address;
<label>lacks a phone format example;
- A link to a modal.
Read on for how we approached the first five of the identified issues.
On his laptop at step 1 of the form, Jamie gave both a mobile number and 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
– Set the focus to the first input with an error.
This required updating the jQuery framework that handles validation.
<button>s weren’t matching
A mismatch of conceptual model to user’s mental models can’t be picked up by 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.
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 two
The last thing Jamie commented was, “I would have thought neither would be selected and you’d have to select one.” The
<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 Russ Weakley and 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.
Spinners on postcode input
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 blind participant and exploded the time to complete this field.
Adam Silver wrote a blog post, When to use the number input, explaining the most inclusive way to capture numeric codes is to use an
input type="text" with a
pattern="[0-9]*" attribute. This removes the spinners both visually and to screen readers. Additionally, some smartphones will render a chunky number-pad for easy entry.
<article> on a
<article> tag was left over from an early page template. Screen readers announce “article” and that’s just confusing when heard on each step of a form wizard. We removed HTML5 article elements from the templates.
Driver’s licence … ineligible
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 reduce the remediation efforts needed 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.
Testing with blind people is great for uncovering issues like mismatched mental models and any keyboard operation issues too. Things we won’t learn from blind users are issues such as low contrast, text too small, confusing visual hierarchies and spacing issues with touch targets. Broadening our testing pool to include low-vision and mobile users should help us learn how to design better interfaces.