This is a technique pulled from KnowledgeBase, a digital accessibility repository available through TPGi’s ARC Platform. KnowledgeBase is maintained and consistently updated by our experts, and can be accessed by anyone with an ARC Platform subscription. Contact us to learn more about KnowledgeBase or the ARC Platform.
hr
When it comes to the web, we all have to deal with forms. When you subscribe to an email newsletter – that’s a form. When you apply for a credit card online – that’s a form. When you declare that you’re an adult – that’s a form. When you order a pizza online – that’s a form. Sometimes, it feels like all we do on the web is fill in forms.
The wording of labels and instructions provided to users as they complete an online form must be clear, unambiguous, and easy to follow. The aim is to help the user complete the form without making errors. If they do make errors, the instructions on how to locate the errors and fix them must also be clear, unambiguous, and easy to follow.
Like so many things, this becomes both more complicated and more important when the person filling in a form has a disability.
For this article, I’m going to restrict myself to the content of those labels and instructions. How a form is made accessible to, say, assistive technologies like screen readers or users with color vision deficiency, is another matter. I want to focus here on the language and meaning of the words used to tell a form user what to do.
Who’s affected?
First, we have to understand that a number of people with a range of impairments of varying severity can have trouble understanding the words used in form labels and instructions.
Users most affected by the language and meaning of the words used to tell them how to complete a form include:
- People with dyslexia
- People with dyscalculia
- People with intellectual disabilities
- People with attention deficit disorders
- People with developmental disabilities
- People with learning disabilities
- People with acquired brain injuries
- People with dementia
- People with various conditions that affect cognitive ability
- People with low literacy
While low literacy is not in itself a disability, it can be associated with specific disabilities including all those mentioned, as well hearing and vision disabilities, due to a lack of adequate educational opportunities.
The impact on some people with disabilities can be so serious as to prevent them being able to complete a form at all, yet people are often expected to fill in online forms that deal with the most important issues in their lives, including their legal status, finances, health, education, employment, independence, and freedom.
What does WCAG say?
The Web Content Accessibility Guidelines (WCAG) include several relevant Success Criteria at Level A or AA:
- 2.4.6 Headings and Labels (Level AA)
- 3.3.1 Error Identification (A)
- 3.3.2 Labels or Instructions (A)
- 3.3.3 Error Suggestion (AA)
- 3.3.4 Error Prevention (Legal, Financial, Data) (AA)
For example, SC 2.4.6 Headings and Labels (Level AA) requires that “if labels are present, they must be sufficiently clear or descriptive”. However, there’s no clear benchmark provided as to what exactly “clear” or “descriptive” means, nor how the clarity or descriptiveness should be judged to be “sufficient”.
It’s worth noting that the people who create form labels and headings are not always the best qualified to make such judgments, i.e., visual designers and front end developers.
Nor are the words used on a form always based on the results of usability testing, and especially not with people with disabilities.
To properly satisfy the requirements of the relevant Success Criteria, expertise needs to be applied that focuses on the language of web content.
By making instructions on forms easy to follow for people who have trouble with words due a disability, you will make forms easy to complete for everybody.
Other Level A or AA WCAG Success Criteria may be relevant to understanding visible forms messages, such as SC 2.4.3 Focus Order, or making it easier for users to complete forms, such as SC 3.3.7 Redundant Entry (in WCAG 2.2).
There are also many other WCAG Success Criteria that focus on making web content perceivable to, and operable by, people with disabilities, including online forms.
What makes forms messaging accessible?
There are two main areas that need attention when it comes to forms messaging: the labels and instructions that tell users how to complete a form, and the error messages they receive if a form is not completed correctly.
The aim is to improve the former enough to minimize the need for the latter. While this can broadly described as “using plain English”, there are some specific factors and guidelines to consider.
Labels and instructions
Introduce. A short text introduction to a form can make all the difference. Give users context, give them confidence and explain that if errors are made they will be given the opportunity to correct them.
Provide specific labels. You might think that text saying “sign up below” is enough but many users won’t know whether you mean a name, an email address, or something else. Give fields visible labels.
Be consistent. Don’t say a field is “compulsory” in one place, “mandatory” in another and “required” in a third. Pick a wording style and stick with it.
Don’t assume. Not everyone knows that an asterisk means a field is required. And don’t assume that everyone understands that the word “asterisk” refers to the star symbol above the number 8 on a keyboard. A note at the top of a form explaining “You must complete fields that are marked as required” helps. Then adding the word “required” to a field label makes sense. Add a reference to asterisks if you’re using them. If many or most fields on a form are required, it’s entirely reasonable to mark only the optional fields with “optional”. Again, a note at the top should explain this.
Group. Put related fields visually close to each other so that users can see this group of fields is for their street address, and that group is for their postal address (let them copy one to the other if they’re same, or pre-fill it for them).
Explain. If someone’s buying a hat online, tell them why you need their telephone number – “so we can let you know quickly if your order is delayed”. Use words directly related to the input or action required.
Autocomplete. Enabling autocomplete or autofill on fields lets users complete a field from data stored in their browser, making form completion easier and more accurate, especially for people who have trouble remembering things. For the same reason, don’t disable copy and paste for password fields, and let password managers do their thing.
Provide options. Many people find it much easier to select an option from a provided list. Let them do that when it’s possible and appropriate.
Avoid cultural bias. You might understand what “Christian name” means, but people from other cultures may not. Be aware that some cultures put what European-based cultures think of as their first name last. If your form is being used by people outside the USA (not unusual on the global web), it might be smarter to say “postal code” rather than “zip code” or even “postcode”.
Use plain language. Labels such as “First name” and “Last name” are more readily and widely understood than “Christian name” or “Given name”, and “Surname” or “Family name”.
Don’t trust placeholder text. The problem with putting field labels or instructions inside the input field is that it disappears when the user moves focus into the field, which means they have to remember what the placeholder text said, an unreasonable burden for some people. Even “flyaway” text that floats to a position above the field is problematic for people using assistive technologies. Further, placeholder text misleads some people into thinking a field has already been completed.
Encourage review. Put a text message before the user reaches the Submit button advising them to review the form, check that all required fields have been completed and that they are satisfied with their field entries. Yes, the user has an implicit responsibility to do this, but it doesn’t hurt to make it explicit – in a friendly tone.
Choose your words. Developers know that people submit forms, so it makes sense to them to use that word on the Submit button. But some people understand the word “submit” to mean “yield” or “give up”. Maybe it would be clearer to use “Send” or even “Send the form”, or a verb that is more closely related to the context of the form, like “Subscribe” or “Register”.
Provide examples. If input is required in a specific format, give the user an example. This is helpful with most kinds of data but especially that which involves numbers, such as dates, money, and account details.
Error messages
Avoid colloquialisms and jargon. “Whoops” and “Oh-oh” don’t necessarily have the chummy effect you might think. “404” is a reference most people won’t understand. “Surfin’ ain’t easy and right now you’re all at sea” is incomprehensible to many people. Be direct and clear.
Don’t be judgmental. “You made a mistake”, “You used the wrong format”, “You failed to complete the form” all place the blame on the user. Maybe it’s not their fault.
Don’t be robotic. “Unable to connect”, “Errors found”, “Form incomplete” are all unfriendly and impersonal. Using full sentences is more human.
Don’t interrupt. Pointing out errors inline as soon as a user leaves a field (or worse, before they’ve even completed the field) is just plain rude. Let the user complete the form, submit it and, if there are errors, redisplay the form and tell them what went wrong. If there are several errors, move focus to the top of the form and display a message like “We couldn’t accept your form because there were some errors, or the form was incomplete. Click on each item in the list of fields below to go to that field for details.” Then list the fields (not the errors) and link each item to the relevant field.
Put text describing the error after the field label but before the input and describe how to fix the error. When the error has been fixed, link back to the error list at the top of the page, with the fixed error removed. If a form has only a single error on submission, redisplay the form and move focus to the field in question, again putting text describing the error after the field label and before the input.
Be clear. Putting error messages in a different color to the main text is good (yes, red is the convention but you don’t have to use the color for “danger” or stop. Consider using a different color, as long as it’s distinct from the main text) but be aware that people with some color vision deficiencies may not discern the color difference. Making the text bold will help it to stand out, and adding an icon will also help (a circle with a cross in it is common, but an exclamation point may be a better way to say “please pay attention to this”).
Be specific. Saying “email format invalid” is not very helpful and doesn’t tell the user how to fix the problem. Something like, “The email address must contain an @ symbol” is better.
Research and test. Use existing research, read up on user experience, accessibility requirements, and best practice. Most importantly, conduct your own research and usability testing. Track errors that users make on your forms and analyze what you can do to minimize those errors.
All of this is fiddly and requires work. That work pays off, however, in having users make less mistakes and feel better about your forms if they do make mistakes and need to fix them.
Like a lot of digital accessibility work, once you establish and implement the principles of good forms messaging, you end up with a design pattern you can reuse and adapt to specific circumstances and needs. A model worth examining is Adam Zerner’s example of an accessible form.
Following these guidelines to meet the Level A and AA WCAG Success Criteria referred to above and applying them to all types of web content will also go a long way towards conformance with these Level AAA Success Criteria:
- 3.1.3 Unusual Words
- 3.1.4 Abbreviations
- 3.1.5 Reading Level
- 3.1.6 Pronunciation
- 3.3.6 Error Prevention (All)
Depending on the nature and context of your forms, it won’t always be possible or desirable to follow all the suggestions I’ve made here. There may be times when you feel using a jokey tone – or a more severe tone – is appropriate. At the very least, though, you should put some thought into your form messages and consider the needs of people who may have trouble understanding them due to a disability. It’s just good form.
Resources
- Adam Silver: Form Design Patterns (book)
- GOV.UK Design System: Error message
- Nielsen Norman Group: Preventing User Errors: Avoiding Conscious Mistakes
- Vitaly Friedman: Designing Better Error Messages UX
- Plain language
- Plain English Campaign
