Accessibility testing a multi-channel form wizard

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

World Interaction Design Day – Diversity & Inclusion in Design – Talks & Panel

Tuesday, Sep 25, 2018, 6:00 PM

511 Church St Richmond , AU

88 Members Went

As part of World Interaction Design Day (IxDD) Melbourne Web Accessibility and Inclusive Design will be hosting talks and panel discussion on the importance of diversity and inclusion in design. Panel Members: Louise Long (@longlou) – Service Design Director, Today A recognised design leader, Louise has honed her service design skills over 30 years…

Check out this Meetup →

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

Prior to September 2018, Become a Library member was a single page web form on which I’d led mobile form improvements for better UX. The registration process dumped everyone’s input into a holding bay in a database for manual processing and distribution of a plastic member card. 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.

The wizard design pattern

“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 the Vision Australia Library, 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.

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.

Mobile form improvements for better UX – registration

Part of White Night Melbourne 2018 (February) was a membership drive utilising our website member join form. White Night runs from 7pm to 7am, when people carry their mobile, not a laptop. Completing the old join form on a mobile was a poor experience. I drew upon HTML5 for Web Designers and Mobile First to come up with improvements to the join experience. I designed four changes intent on making it easier to complete the form via mobile devices. It was a thrill to see this first iteration implemented in time for the event.

Mobile form improvements made it faster to complete; easier to fill out; and gave more accurate data.
UX improvements to form completion: faster, easier, and more accurate.

The old join form

The old form contained 17 fields. It was never designed to be completed on mobile devices.
The old join form was designed to be filled out on desktop or laptop with a physical keyboard.

There were 17 fields in the old join form including Country selection which defaulted to Australia. To complete the old form, Australians were to fill out 9 required fields, and 7 optional fields. There was no default value selected for State. Choosing your state was required for all Australians despite that 90% of the registrations were Victorian.

A phone number was a required field. A separate field asked for a mobile number if you wanted to receive SMS notifications of items ready for collection. If you wanted membership renewal notices, you had to type your email address twice.

Poor experiences completing the old join form on mobile

Entering a phone number on the old form was difficult.
Onscreen numeric keyboard for digits 1 through 0 across the narrow width of mobile phone offer small touch targets.

On a touchscreen device, the phone and email inputs did not provide helpful keyboards to enter details easily or accurately. For instance, entering a phone number mandated an additional tap to switch to a numeric keys. The 10 digit buttons across a narrow screen are small touch targets. It was even harder to enter an email address like After typing the initial letters, you’d have to switch:

  1. to numeric keyboard for the @ symbol
  2. back to enter more letters
  3. again for every full stop “.” character!

Then the form asked people to confirm your email address, so do all that tapping and switching all over again!

A column chart comparing completion time on the old form across desktop, mobile, and tablet devices. From the 2016-2017 financial year to the 6 months of July to December 2017, form completion time took longer on mobiles.

From July to December 2017, analytics reported that completing the old form on a mobile took over a minute longer than on a desktop.

Completing the old form on a mobile was a poor experience that took too much time. This presented a significant barrier to our membership drive. The mobile form improvements sprint was on!

Improvements to form input operability

Collaborating with our developer I set out to make mobile form improvements that would result in a superior joining experience.

Select a default that matches most users

With 90% of Australians choosing Victoria as their state, it made sense to pre-populate this as the default selection. Setting this as the default reduces the effort for the majority of users. It also maintains the same number of interactions for interstate or international visitors.

Map of Australia with state of Victoria highlighted. 90% of forms completed had Victoria selected.
See inspiration for other form inputs you can pre-populate with The Power of Defaults.

Using input type="tel" for a phone number

By changing the HTML input type to “tel” it becomes easier for mobile users to operate a familiar, large button dial keypad to enter their phone number. Additionally, autofill options appearing above the dial pad only need one tap to input your entire phone number.

Mobile form improvements make phone numbers easy to enter.
Entering a phone number becomes easier on mobile.

A checkbox and validation for SMS opt in

Internal data showed when members opted in for SMS notifications, we don’t need a secondary phone number to contact them. Instead of a second phone number for SMS notifications, I changed the design to one phone input and a checkbox. I worked with our developer to create validation code. When the SMS notifications checkbox was checked, validation checks the phone number is in the format of an Australian mobile.

Using input type="email"

Mobile form improvements make email addresses easy to enter.
Entering an email address becomes easier on mobile.

By changing the HTML input type to “email” it becomes easier for mobile users to operate a keyboard with an @ symbol, and common .com and .au domain extensions available from a long press on the full stop key. Like phone, email autofill options require just 1 tap. Furthermore, the HTML5 input type=”email” provides basic email address format validation in all modern browsers, not just on mobile. I used all this as a compelling argument to remove the Confirm your email address question.

Outcomes result in a superior joining experience on your mobile

We changed the doctype to HTML5, made a handful of code tweaks, and tested via BrowserStack and on real mobile devices too. Then our developer deployed the changes just in time for the weekend event. Thank you Troy!

2 pie charts comparing devices used to complete the old form versus new. Desktops were used for 3/4 old form completions; then mobiles were used for 1/2 new form completions.
Desktop devices reigned old form completions (74.3%) through January. On the weekend of 17th to 18th February, the new form saw mobile rise to 49.4% of completions.

In the 6 weeks leading up to deployment, desktop devices continued to reign with 74% of form completions, while mobile had less than 18%. Over the weekend of White Night, nearly 50% of forms were completed on mobile devices.

A column chart comparing completion time for the old form versus the new, across device types. Desktop became 33 seconds faster; tablets 66 seconds faster; mobile 94 seconds faster.
A column chart comparing the time taken to complete the form across desktop, mobile, and tablet devices. From January 2017 to the weekend of White Night, form completion time reduced on all devices, especially mobile.

In terms of time taken to complete the form, this release leveled the playing field across devices. The new form saves mobile users 94 seconds. These mobile form improvements also made the desktop experience faster. Throughout 2017, there were 22,704 join forms completed. If last year’s registrations all used the new form on mobile, we’d save 593 hours!

This year’s event was a trigger to embrace mobile form improvements. These improvements make it faster to complete, easier to fill out, and provide more accurate data. The design principles underpinning these changes persist beyond White Night. No matter where or when, completing the form on your mobile is now a superior experience. The design shift set us on a course for future iterative developments of member registration and innovation in onboarding processes.

Service blueprint supporting Library membership joining

In January 2018, I created a service blueprint exposing inefficient and painful internal processes of how the business delivers membership. 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, both from offsite and onsite.

Short of emotional data and user pain points, I relied on my heuristic review of the artifacts and backstage processes, 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, a service blueprint, not a customer journey map.

Where journey mapping focuses on exposing the end-to-end of your customer’s front stage experience, blueprinting focuses on exposing the surface-to-core of the business that makes up the backstage and behind the scenes of how you deliver and operate, and ties that to the customer’s experience.

The difference between a journey map and a service blueprint by @erik_flowers and @meganerinmiller
Service blueprint exposing the business of how membership is delivered and operates.
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 website 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! Thankfully the HTML and server-side technologies are bespoke. These frameworks give us the freedom to design, develop, test and iterate mobile form improvements and more 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:

  • traveling to the Library is unnecessary
  • finding your way through a complex building to a registration desk is avoidable
  • interacting with staff is not required

By post has slower delivery and is a kind of self-service method of receiving your Library card. This option also required “great lengths to patch it together” in terms of intensive 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.

After sharing the blueprint

This service blueprint indicates “inefficient and painful internal processes” surrounding postal delivery of member cards. Five months after sharing the blueprint, in June 2018, I lead a project which would bring about:

  • digital distribution of membership
  • faster delivery of member benefits
  • automation of manual processes

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