Accessibility testing a multi-channel form wizard

I gave a lightning talk as part of World Interaction Design Day #IxDD at the Melbourne Web Accessibility and Inclusive Design meetup in September 2018.

Glad I brought my presentation on a USB – thank you
Melissa Coltzau for the working laptop connection!
Slides from my lightning talk on lessons learnt from our pre-launch test of a multi-channel form wizard.

From plastic cards to form wizard

Before September 2018, Become a Library member was a single page web form that dumped everyone’s input into a holding bay in a database. Shifting from plastic member cards to digital distribution methods meant business process re-engineering and converting the single page form into a multi-step wizard.

Bring in the wizard

“a powerful design pattern … to simplify complex processes performed infrequently or by novice users.”

Wizards: Definition and Design Recommendations by Raluca Budiu on June 25, 2017

Manual accessibility testing

In September 2018 I conducted manual accessibility testing on the first iteration of form wizard and the new self-service join processes. My colleague Janet Austin assisted with the session. Jamie Kelly, a blind person from Vision Australia, was our participant. He tested two scenarios:

  1. laptop + Firefox + JAWS screen reader → email membership delivery;
  2. iPhone + Safari + VoiceOver → SMS membership delivery.

Imperceptible validation

I was shocked that the first show-stopper issue occurred in the first step of the form wizard. A validation message for Australian mobile number that appears visually in red text, wasn’t announced by the screen reader. Without assistance, it was impossible for our screen reader user to discover why the form was stuck on step 1, let alone recover from the error.

A validation error is visible but not announced by screen reader.

Progress for all

It’s vital to show your progress, to “distinguish the current step, and how many steps there are left.”

Wizard Design Pattern by Nick Babich on April 8, 2017
Our visual 5 step progress bar for sighted users.

We need to provide a sense of progress to screen reader users too. 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.” We use the Bootstrap .sr-only class to hide text on all devices except screen readers.

HTML and CSS for screen reader only progress indicator

Our participant heard and understood they were making progress. ☺️ The page title was announced as “Library member registration | Step 2 | State Library of Victoria” and this was reinforced by hearing “Progress: 40%”.

Buttons ≠ mental model of radio inputs

At step 2 of the wizard, users must explicitly choose their preferred method for receiving their membership: SMS or email. Their contact details are displayed with each option so they can check their mobile number or email address for correctness.

Two options coded as <button> elements did not match the user’s mental models.
<button type="submit" name="confirm" value="sms"> <button type="submit" name="confirm" value="email">

These buttons were the only form controls on step 2. Clicking one of the buttons would indicate your preference, SMS or email, and submit the form to step 3. These buttons completely baffled our participant. We’d been so focused on making easy interactions with large touch targets for the new kiosk devices, that we lost sight of underlying semantics (or lack thereof) and accessible form design patterns.

Our participant pointed out that the buttons really should be radio inputs. Exacerbating the mismatch of conceptual to mental model, is that step 2 lacked an explicit Next button. The design didn’t align with their mental models of interfaces or flow!

An inclusive design solution for radio inputs

Two days before our testing session, Hui Jing Chen posted Customize Radio Buttons without Compromising Accessibility, an inclusive design solution that makes radio inputs work for screen reader and touch screen users alike.

Log issues and iterate

Lastly, I recommend Eric Bailey’s advice in The Importance Of Manual Accessibility Testing: log issues you’ve identified. Also rate identified issues in terms of user value and team effort, to prioritise which changes to iterate in your upcoming sprints. For our next iterations of the form wizard, we’ll work on fixing form semantics and validation issues.

See the thread at for links to references cited.

Current state of becoming a Library member

In January 2018, I began my new role as Digital User Experience Manager in the Digital Experience team at State Library Victoria. My first task was to map the current experience of joining the Library to attain free membership, both from offsite and onsite.

Short of emotional data and user pain points, I relied on my heuristic review of the artifacts and process, as well as information gathered from internal sources including:

  • conversations with key colleagues;
  • YouTube channel content;
  • Google Analytics reports.

Analysing and synthesising the data at hand, I created the following map (more a service blueprint than a journey map).

A service blueprint of joining the Library through stages of: initiate; web form; collection choice; manual processing; welcome; and membership.


Whether onsite or offsite, people either self-directed or were staff-mediated to start their join the Library task. Some people arrived via a Register link in the masthead, others were directed to a dedicated computer at a staffed registration desk.

Web form

Users completed a web form that lacked optimisation for touch devices. It took 40 seconds longer to complete on a mobile compared to a desktop device. The HTML and server-side technologies are bespoke, giving us the freedom to design, develop, test and iterate many improvements over the following months.

Collect choice

One question on the form asked people how they’d like to receive their Library card: at the Library; or by post. The vast majority, 77%, chose to receive their card by post. Choosing by post means:

  • no need to travel to the Library;
  • no need to find your way to a registration desk in a complex building;
  • no need to interact with staff.

By post was the slower and kind of self-service method of receiving your Library card. This option also had the greatest impact on manual processing efforts.

Manual processing

At the Library

Only 23% chose to present identification to staff at the registration desk in order to receive their Library card. Staff would retrieve a plastic card from stock, make record adjustments in a computer system, then issue the card.

By post

After removing spam registrations, and resolving incomplete or incorrect addresses, staff would:

  1. Retrieve a plastic card;
  2. Make record adjustments in a computer system;
  3. Match the card with the corresponding named and addressed envelope;
  4. Pack in a welcome letter.

Then a batch were taken to dispatch where, on business days, Australia Post would commence delivery.


Members who chose by post received their card and a generic welcome letter. No longer was the letter personalised. It wasn’t even customised: members residing outside Victoria got the same messages about accessing e-resources – a privilege non-Victorians are ineligible for!

Membership begins

Once people found their way to the registration desk, joining onsite only took a few minutes. For Victorians to receive their card in the post, it took between 2 to 6 days, then they could begin accessing member benefits.

End note

This blueprint indicates focus areas for a project that was initiated 5 months later, in June 2018. I lead this project which would bring about:

  • faster delivery of member benefits;
  • automation of manual processes.

In future posts I’ll describe pertinent aspects of the project. With over 20,000 registrations per year, this simple transaction fits neatly into what Gerry McGovern calls a sweet spot for digital self-service.