Input width to guide sighted users

Setting the input width to guide sighted users reduces cognitive effort needed to fill out forms.

… you might be tempted to give every address field the same width.
But giving the postcode field the same width as every other field increases the cognitive effort needed to fill it out. This is because the width gives users a clue as to the length of the content it requires.

Silver, A. (2018). A Checkout Form. In Form Design Patterns. Smashing Media AG.

To reduce cognitive effort for sighted users to input a postcode, a payment card security code, or any field where there is a known maxlength, I’ve created HTML and CSS code to set the width of form field. In addition to guiding sighted users, I’ve also added attributes to make completing on smartphones as easy as possible.

For example, Australian postcodes are 4 characters long. Payment card security codes are generally 3 digits, with American Express being 4 digits. Setting the width of the input just a little wider than this maximum helps sighted users understand what is expected.

See the Pen Input width to guide sighted users by Vernon Fowler (@vfowler) on CodePen.


input type

My main reason for switching the input type away from type="number" to type="text" is I discovered the presence of spinner buttons causes painful experiences. In September 2018, manual accessibility testing a form postcode field with type="number" caused confusion with increment and decrement spinbox announcements. There was also frustration with operating the keyboard to enter the 4 digits. If in doubt, check Silver’s list of criteria for When to use the number input.


Adding autocomplete="postal-code" benefits everyone completing a form that requests personal data. Autocomplete can save time, eliminate typing or spelling errors, and make it easier to complete for anyone with cognitive or mobility impairments. In Exploring WCAG 2.1 — 1.3.5 Identify Input Purpose, Gibson’s video clearly demonstrates how form fields with autocomplete contrast those without. Lastly, using appropriate autocomplete attributes is a requirement for Level AA compliance with WCAG2.1.

pattern and inputmode

Using pattern="[0-9]*" validates that the input only contains digits 0 through 9. As Australian postcodes do not contain letters or any other characters, this seems warranted. To trigger a large numeric keypad on Android and iPhones with iOS 13, add inputmode="numeric".

Large numeric keypad for iOS 13 with inputmode=”numeric”

May 10th, 2019: With iOS 12.2 Apple appears to have introduced a bug where the numeric keyboards … no longer invoke the true “numeric” keyboard with the enlarged number keys (beyond the “tel” keyboard).

Touch Keyboard Types ‘Cheat Sheet’ by Baymard Institute

Use to test inputs for which virtual keyboard corresponds to each inputmode on your device. With inputmode="numeric" iOS 12.2 iPhone users see the keyboard with keys 1 through 0 across the top row, with special characters below.

When inputmode="numeric" iOS shows a helpful onscreen keyboard with keys for 1 through 0.

minlength and maxlength

Postcodes in Australia are all 4 digits, but we’re allowing at least 3 digits for anyone forgetting a leading zero from postcodes such as 0800—0899. Thus the minlength="3" maxlength="4" attributes will validate the input has the correct length. (By the way, a leading zero is another reason input type="number" is unsuitable.)


I’ve created style rules for any input that has a maxlength attribute. I set padding vertically and horizontally via padding: 0.3rem 1ch; because, as McDowell concludes, “rems are good for vertical cadence, and ch is good for horizontal cadence” (Using Ch, An Underappreciated CSS Length, McDowell). I also use the ch unit to calculate the input box width. Before going further, note that:

… a ch unit is equal to the width of the 0 (zero) glyph found in the font used to render it. This definition works for monospaced fonts (where every glyph shares an identical width), but it’s completely unreliable for proportional fonts.

Making Sense of Ch Units by John D. Jameson

Rather than do extra calculations to use proportional fonts, I’ve chosen monospace fonts to help users distinguish a 1 from an l, or a 0 from an O, and any other similar looking characters. Try entering 1lO0 in the input box above to see how the characters render visually with these fonts.

Finally, with Australian postcodes at 4 characters, I set the width of the input box: input[maxlength="4"] {
width: calc(4ch + 2ch + 1ch + 2px);

/* maxlength + padding + breathing space + border */

I add 1ch of breathing space on McDowell’s formula. I found his fudge factor of 0.1ch put the blinking cursor hard up against the right edge of the input box. Sometimes the leftmost of my 4 characters had their left edge cropped. There was also the question: Had I typed more characters and these are the most recent 4? Don’t make me think. Adding 1ch of breathing space makes it clear that the input box has enough characters, and not more than the maximum.


From research to design: iterating a form wizard 🧙

This 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 talk demonstrates how we overcame both 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:

  1. Using a laptop, Firefox, JAWS, and email to receive membership.
  2. 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;
  • An <article> tag announced on every step of the <form>;
  • A driver’s licence was the only example document as proof of address;
  • A <label> lacks a phone format example;
  • A link to a modal.

Read on for how we approached the first five of the identified issues.

Imperceptible validation

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 <label>;
– 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 <button> elements.

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 <form>

An <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.

Next steps

To reduce the remediation efforts needed in future, and have better designs out of the box, some next steps I’m taking include:

Photo by Ant Rozetsky on Unsplash

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.

HTML5 article tags on a form removed

During manual accessibility testing of a form wizard in September 2018, HTML5 article tags were announced by the screen reader. This confused our participant on every step of the form! Sorry Jamie.

Video queued up at 7 minutes 52 where <article> tag announcement causes confusion and irritation.

Prioritising problems

Using the three question decision tree described in How to prioritise usability problems, I was able to classify this issue as medium severity.

Three questions in a process diagram to define four severity levels of usability problems
  1. The article tag announcement wasn’t during a critical or frequent (sub-) task, so it’s not on a red route.
  2. The announcement was not difficult for users to overcome. In virtual/browse mode the screen reader intercepts presses of “the up/down keys [to] move focus to the previous/next line”. (Quote from Léonie Watson on Understanding screen reader interaction modes.)
  3. The article tag was announced on every step, before pre-amble text or any form field. Because this issue occurred persistently throughout the wizard, I rated it as a medium severity.

Dr David Travis says we should interpret a medium severity problem as one that “will make some customers feel frustrated or irritated but will not affect task completion.” The video from our test session above illustrates minor confusion on the first occurrence leading to irritation after repeated occurrences on every subsequent step of the form wizard.

Must do manual testing to learn

It was a trivial code fix in the template, a task resolved in our late-November deploy. How did article tags get in our <form> wizard in the first place? Back in February this year I worked with our developer to introduce HTML5 to improve completing the form on mobile devices. Still we can’t pinpoint how article tags found their way into the templates. I have not discovered an automated testing tool that would’ve alerted us to the presence of this undesirable combination. Again I find myself highly recommending The Importance Of Manual Accessibility Testing. Without manual testing, we wouldn’t have learned about this and many other issues that harm accessibility of web forms.