The document discusses essential guidelines for designing accessible web forms, emphasizing the importance of redundancy in conveying information to accommodate various user needs. It covers key aspects such as label positioning, font size, visual hierarchy, and the use of semantic markup to enhance usability for all users. Ultimately, it stresses that accessibility should not be sacrificed for visual aesthetics and provides specific design strategies to improve user experience.

1. Designing
Usable Forms
by Rick Dzekman

2. Topics
1.Accessibility
2.Context
3.Design

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

4. “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_st
airwell._(2610265332).jpg

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

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

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

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

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

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

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

12. Remember
"it doesn't look as good" is never an
acceptable excuse to avoid accessibility

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

14. Some specific accessibility issues
These next slides
describe specific
accessibility pitfalls and
how to avoid them
from the beginning

15. 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">

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

17. 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?

18. Why go through all
this trouble? You risk
making it harder to
less-abled users.
All so you can hide
content in the
design?

19. 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%)

20. 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?

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

22. 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"

23. Remember
"it doesn't look as good" is never an
acceptable excuse to avoid accessibility

24. Context of web forms
Context matters
2

25. 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?

26. 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?)

27. Don't be absurd
Another hypothetical question
Do you think having a label underneath
the input could ever increase usability?

28. 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?

29. “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

30. 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?

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

32. 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 Nielsen
http://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!

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

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

35. What language is it in?
English
Life insurance company employee
Spanish
Empleado de la compañía de seguros de vida
German
Lebensversicherungsgesellschaftsangestellter
Chinese
寿险公司员工
Arabic:
‫موظف‬‫الحياة‬ ‫على‬ ‫التأمين‬ ‫شركة‬

36. Multilingual Web
How 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?

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

38. Designing web forms
Concrete design tips
3

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

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

41. 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/

42. 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 ask
1. 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?

43. 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/

44. 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/

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

46. 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!)

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

48. “
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

49. 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"

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

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

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

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

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

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

56. 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!

57. Thanks!Any questions?
Find me on Twitter
@rickdzekman