Designing Usable Forms

by Rick Dzekman

Topics

1.Accessibility

2.Context

3.Design

Accessibility in web forms"it doesn't look as good" is never an acceptable excuse to avoid accessibility

1

“But the building's facade doesn't look as good with a wheelchair ramp”

- Some horrible person

Consider a real world analogy

“We can't have a handrail in the stairwell, it would make it look ugly”

- Another horrible person

https://commons.wikimedia.org/wiki/File:SSF_Main_Library_wheelchair_ramp_1.JPG

https://commons.wikimedia.org/wiki/File:Orange_stairwell._(2610265332).jpg

Different types of accessibility needs

Accessibility isn’t just about screenreaders

￭ I experience eye strain – I browse the web at 150% zoom

￭ My dad is inexperienced with technology – he can sturggle working out what is clickable

￭ My mum needs glasses to read the screen – small or low contrast text is very problematic

￭ My cousin has RSI so using a mouse can be painful – he prefers keyboard navigation

If you want to make your UI so user-friendly that anyone can use

it

Then you need to make sure everyone can use it

Simple guidelines

If you follow these guidelines accessibility is going to be a lot easier. Your design should be:

￭ Simple￭ Structured￭ Consistent￭ Intuitive

￭ Redundant

By design redundancy I mean having more than one way to convey contextual information.

These are obvious

What is this?

Redundancy in design – Example #1

Bad Good

Only colour is used to distinguish a link from regular text

Both colour and underline is used to distinguish a link from regular text

Redundancy in design – Example #2

Bad Good

Important information is only highlighted using an icon

A label is added to the icon to show that this section is important

Redundancy in design – Example #2

Bad Good

The two inputs don’t have form labels A fieldset is used to group the fields and each one is given a label

Redundancy in design – Example #2

Bad Good

Only colour is used to convey an error Colour, text and an icon is used to convey an error

Remember"it doesn't look as good" is never an

acceptable excuse to avoid accessibility

Why redundancy?

When you add redundancy to both the design and the code you minimise the risk of accessibility issues.

This is because a lot of accessibility problems are caused by assumptions, e.g. assuming that the user:

￭ Can see￭ Can tell the difference between red and green￭ Understands internet conventions￭ Is able to concentration / focus

Some specific accessibility issues

These next slides describe specific accessibility pitfalls and how to avoid them from the beginning

Get the basics right

￭ Use a large enough font size

￭ Make sure you have high contrast￭ Consider edge cases: e.g. disabled buttons

￭ Have a strong visual hierarchy￭ Do your headings follow both a semantic (h1-h6) as well as size order?￭ How do fieldsets look in your hierarchy?

￭ Use the for=“id” attribute to link labels to inputs￭ i.e. <label for="dob">Date of birth</label>￭ <input type="text" id="dob">

Use semantic markup

￭ <fieldset> to group inputs

￭ <aside> for help text

￭ If it goes somewhere use <a href=“link”> if it does something use <button>￭ Never use <a href=“#”>

￭ <dl> (definition list) for displaying key/value pairs￭ e.g. showing previously submitted responses:

Name: John Smith^ definition term <dt> ^ definition <dd>

Help text

If help text is necessary don’t hide it!

When you hide content you encounter accessibility issues:

￭ Older users / users with cognitive difficulties may not be familiar with the convention and not know to hover￭ You need to write separate code to account for keyboard navigation users￭ What will you do about screen readers?￭ You have to be careful about users with different browser modes (e.g. high contrast) who may not see the icon at all

Why hide this content behind a hover?

Why go through all this trouble? You risk making it harder to less-abled users.

All so you can hide content in the

design?

Help text

Is your form long enough to need a progress bar?

Most progress bars only use colour to communicate how far along you are. This makes the assumption that your user can actually see the colour!

Use redundancy:￭ Use an ordered list￭ Add a (current step) indicator￭ Advise the user how far along they are with text￭ E.g. (step 1 of 3) or (Progress: 50%)

Handling errors

￭ Make sure you use more than just colour to communicate errors

￭ Avoid using red for marking mandatory fields to avoid confusion

￭ If errors are dynamic (either as the user types or after they submit the form) how will you communicate these dynamic changes to a screen reader?

Don’t hide labels

￭ Consider the example with the "from date" and "to date". If you add a label just for screen readers but it's not visible you are not only adding extra development work but also pointlessly hiding content from the user.

￭ On top of that you are thinking of accessibility as only about screen readers.

￭ If the content needs a label for some users then it should probably be shown to all users.

Dynamic form changes

Consider this scenario where selecting "add another" causes dynamic changes to the page:

￭ Use `aria-live=assertive` to notify screen readers of a change to the DOM

￭ Change the `focus` to the first input in the newly created element

￭ Use useful anchor text on the button, e.g. "Add another task" vs simply using "Add another"

Remember"it doesn't look as good" is never an

acceptable excuse to avoid accessibility

Context of web formsContext matters

2

Consider this…

Keeping in mind everything I've said about accessibility, what do you think about this question?

Is it ever OK to hide a label from a sighted user?

There are exceptions to rules

Does this need a label for the input field?

You might not consider it a form - but it is the second simplest kind of form there is. (What's the simplest?)

Don't be absurd

Another hypothetical question

Do you think having a label underneath the input could ever increase usability?

Don't be so close minded

“For one group of participants, we placed the labels above the input fields and, for a second group, we placed them below. When test participants were able to concentrate on their work, there weren’t any differences between the two groups—everybody filled out the form correctly. But when we interrupted them and asked them to fill out the form in a reduced amount of time, the group with the labels below made fewer mistakes than the others.”

"Label Placement in Austrian Forms, with Some Lessons for English Forms" (Roland Feichtinger)http://www.uxmatters.com/mt/archives/2010/10/label-placement-in-austrian-forms-with-some-lessons-for-english-forms.php

Aside: can you think of a scenario for right-hand labels?

“What Matters Most Is Whether a Label Is Close Enough to Its Field

Choose Any Harmonious Arrangement of Labels, Then

Test

- Label Placement in Austrian Forms, with Some Lessons for English Forms

Context is important

￭ What is the purpose of the form?

￭ How long is it?

￭ Who handles the responses?

￭ What language is the form in?

￭ What can a user do once the form is submitted?

Types of forms

￭ Search form￭ Lead capture forms￭ Enquiry / contact us￭ Support requests￭ Registration form￭ Survey￭ Application form￭ … And many others

What is the purpose of the form?

Each one will vary

￭ How long it's likely to be￭ How the user gets there￭ How informed the user is￭ How engaged the user is

Common idioms don't apply in all cases

“Web users spend 80% of their time looking at information above the page fold. Although users do scroll, they allocate only 20% of their attention below the fold.”“Scrolling and attention”Jakob Nielsenhttp://www.nngroup.com/articles/scrolling-and-attention/

Do you think that applies to a registration form? What about an application form? What about submitting a tax return?

Some forms are only for engaged users, other forms are for users who have no choice (consider a form for staff on an intranet)

Users do scroll – context is important!

How long is the form?

At Deakin university, the online application form is over 100 questions most of which aren't seen by most users. Two randomly chosen applicants aren't likely to have seen the same questions. It is dynamic and context driven.

^ ATO eTax – sections > subsections > fieldsets

< Salesforce.com “Free Trial” form

Who deals with the responses?

Remember - your system usually has more than one user. The end user isn't the only one impacted by your design. There are administrators who have to maintain the form and staff who have to do something with the responses.

Sometimes you can offload work to the user, making a form more difficult to fill out but easier to respond to. This might increase the time to respond for staff and as a result improve the ultimate user experience.

Sometimes short-term costs to user experience can have long term benefits.

What language is it in?

EnglishLife insurance company employee

SpanishEmpleado de la compañía de seguros de vida

GermanLebensversicherungsgesellschaftsangestellter

Chinese寿险公司员工

Arabic:موظف شركة التأمين على الحياة

Multilingual WebHow would a long compound word in

German work as a label? How does the design look with a short Chinese label? What about in Arabic where it needs to be right-aligned and read right-to-left?

What happens after the form is submitted?

￭ Can the user edit their response?￭ Can they keep track of the progress? ￭ Can they even see their responses after submission?￭ Can the user save progress and come back later?￭ What happens if the user changes their mind about submitting the form?￭ What happens if the user made a mistake while filling out the form?

Some forms are more important than others. Forms can have legal, regulatory and even financial consequences.

Usability does not trump everything

Designing web formsConcrete design tips

3

Overview

Like a lot of design form design has a subjective component. There are two types of advice for designing forms:(1) Data driven, evidence based design considerations(2) Best practices

Where I advocate a design decision I will identify if it's come from a particular study or piece of research. Otherwise the suggestions are considered best practice. As always be sceptical of “best practices” with no data.

If you are in doubt about any design advice the best (or even only) way to decide for your context is to conduct an AB test.

Wording of your form

￭ Who is the user / how much do you expect them to know?￭ This helps with deciding how technical your language can be

￭ What is your relationship with the user?￭ If you have to ask personal questions it can be important to explain why you are asking this question

￭ What kind of tone does your organisation have?￭ Often a conversational tone can be helpful in communicating with your user

￭ How simple can you make your question while still retaining meaning?￭ Could you offload the complexity into help text?

The best guide comes from Gerry Gaffney's article:"The art of writing very little: how to improve your forms“http://www.formsthatwork.com/TheArtOfWritingVeryLittle

Using placeholders

Key takeaway: Don’t use placeholders

￭ "Eyetracking studies show that users’ eyes are drawn to empty fields"￭ "Disappearing placeholder text strains users’ short-term memory."￭ "It also poses additional burdens for users with visual and cognitive impairments.“￭ "One last issue to consider is that placeholder text is generally bad for accessibility."

"Placeholders in Form Fields Are Harmful“http://www.nngroup.com/articles/form-design-placeholders/

Should you use a dropdown?

The best guide to this question comes from Sarah Miller and Caroline Jarrett in the article "Four steps for choosing form elements on the Web”http://www.formsthatwork.com/files/Articles/dropdown.pdf

Six questions to ask1. Is it more natural for the user to type the answer rather than select it?2. Are the answers easily mistyped? 3. Does the user need to review the options to understand the question?4. How many options are there?5. Is the user allowed to select more than one option?6. Are the options visually distinctive?

Careful use of icons

Icons by themselves on a form can be very risky. In order to communicate an action that a user needs to do it's best to use a combination of an icon and a label.

"There are a few icons that enjoy mostly universal recognition from users. The icons for home, print, and the magnifying glass for search are such instances. Outside of these examples, most icons continue to be ambiguous to users due to their association with different meanings across various interfaces."

“Icon usability“http://www.nngroup.com/articles/icon-usability/

White space

Appropriate use of white space to create visual heirarchy and grouping is vital to form design

￭ "Tip #1: Place the label closer to the associated text field than to other text fields“￭ "Tip #2: Group together related fields"

"Group Form Elements Effectively Using White Space”http://www.nngroup.com/articles/form-design-white-space/

"Users overlook features if the GUI elements are too far away from the objects they act on"http://www.nngroup.com/articles/closeness-of-actions-and-objects-gui/

Minimise the number of questions being asked

Keep your form as short as possible (but no shorter!)￭ If a field is required ask "why is this field required? Do

we actually need it?￭ If a field is optional ask "if users don't have to fill it in, why are we asking them?“

The more questions we ask the user the more cognitive strain we put on them. This increases the chance of abandonment or the user making a mistake. Aim to reduce the number of questions you ask to the bare minimum.

Rather than optional, consider making some questions conditional. So that the user is asked only if their other answers indicate that we need this information.

Responsive forms

Here are a few small tips to keep in mind

￭ Is the font size large enough?

￭ For iOS - if you don't make the input font size 16px Safari will zoom in on the field when focused

￭ Is the right keyboard coming up? (numeric, email, plain)

￭ Have you turned off autocorrect / autocomplete for fields where it's a distraction?

￭ Consider using a toggle instead of a checkbox (note, for desktop this can cause confusion!)

Mandatory* vs (Optional)

This is a largely subjective issue. The question is simple, do you mark mandatory items (e.g. with an asterisk) or do you mark optional items (e.g. with "(optional)").

￭ If every or almost every input is mandatory then it makes more sense to mark optional fields￭ If there are many optional questions it's better to mark mandatory fields￭ Sometimes an (optional) indicator can make things ambiguous (consider checkboxes / document uploads)￭ If there are many forms on the web site or app then you should have a global rule, where individual forms may not follow best practice

“ Where to put the asterisk?

“I was once charged with testing

that. Seriously. $10,000 of manhours testing asterisk

placement.

There was no difference in user performance. At all.“

- Miriam Frost Jungwirth

There are some UX designers who will claim that users are used to the asterisk marking mandatory fields and that optional confuses

users.

However, I have never seen an actual study proving this claim. In all usability tests I've done users have never had problems with

"optional"

Label placement (part 1)

Different label placements serve different functions

￭ Labels on the left hand side of inputs allows for quick scanning of the form. This is particularly useful if users need to edit or review their input and can be useful if they don't need to fill everything out.

￭ Labels directly above the form input make it much simpler to fill out fields one at a time

￭ No labels and using placeholders instead reduces screen space but at the cost of accessibility and bringing its own usability problems

Label placement (part 2)

Keeping the last section in mind it's important to consider what studies have been done. The most famous eye tracking study has shown that labels above form inputs are considered the best:

"Placing a label above an input field works better in most cases, because users aren’t forced to look separately at the label and the input field. Be careful to visually separate the label for the next input field from the previous input field."

"Label placement in forms“http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php

Label placement (part 3)

Eye movement over labels

Left aligned labels require a zigzag reading pattern and lead to longer saccades

Labels above either have low saccades or require only a single eyeball fixation to read the label and focus on the input

Sentence case vs title case

Use sentence case for labels, buttons and headings

According to ISO-9241 sentence case is more readable than title case and should be used instead.

If you're unfamiliar with this standard, read:"What on earth is ISO-9241”http://www.uxbooth.com/articles/what-on-earth-is-iso-9241/

NB. never use all caps for anything you actually expect users to read. All caps is proven to be the most difficult type of text for people to process.

You don't need a long preamble

In my experience testing a form with a long preamble - users skimmed or ignored them. This was true even of older less tech savvy users. In my personal experience I only read preambles if I have trouble with the form. So if there was something important in there I would miss it.

This has also been experienced by others with AB testing:

"Both tests, October and November, showed a significant difference [...] between the conversion rates for the variants with the original preamble and with the [shorter] preamble."

"Making a better web form" - http://www.formsthatwork.com/files/Articles/BetterForm.pdf

Design aesthetics are not important

Colour, shape, position, placement, padding, margins, fonts, etc. make little to no difference to the usability of a form. These aesthetic details should not be our focus.

"tinkering with a design that is reasonably tidy and organized in the first place is unlikely to make a major difference to the success of a form.“

"No significant differences for ... 1. Adding a photo, 2. Adding coloured backgrounds to fields, 3. centring the form in the browser window, 4. adding a blue background to the window"

"Making a better web form" - http://www.formsthatwork.com/files/Articles/BetterForm.pdf

Handling errors

￭ Make the form forgiving - e.g. accept both 03 9999 9999 and 0399999999, fix server-side or with JavaScript

￭ Provide the user on-screen help

￭ Give the user a way to get help outside of the form (email, live chat or even a help desk phone number)

￭ Provide useful errors ("this field is required" rather than just highlighting it red)

￭ Consider providing live feedback. e.g. fields get ticked and turn green when they are completed correctly. But watch out for accessibility concerns!

Thanks!Any questions?

Find me on Twitter@rickdzekman