Input forms are a vital way to interact with users; making them accessible to all users is critical. HTML has many out-of-the-box elements, tags and techniques — outlined and illustrated below — to provide these capabilities.
HTML fieldset and legend tags
When to use the HTML fieldset and legend tags:
DO USE fieldset and legend
- On a single multiple choice question with radio buttons or checkboxes
- On several questions relating to the same topic
DO NOT USE fieldset and legend
On a single form field that asks for a single piece of information
aria-required="true" instead of the HTML
required attribute since the latter is not implemented uniformly across browsers and tends to announce empty required fields as invalid when the user first focuses on the field.
If you have to use the HTML
required attribute, use it in conjunction with
aria-invalid to avoid user confusion.
Code Example 1
<label for="name"> Name </label> <input id="name" type="text" aria-required="true">
Code Example 2
<label for="name"> Name </label> <input id="name" type="text" required aria-invalid="false">
All form inputs must be labelled, so make sure the label tag gets the
for attribute. This ensures the label will get announced when the screen reader user focuses on the field.
<label for="name"> Name </label> <input id="name" type="text">
Invalid fields need visual and non-visual cues to communicate. Use “live regions” so that screen readers will announce the error message:
On page load
aria-describedbyon input pointing to the related error message container
- Error message container gets
aria-invalid="true"on the input for non-visual
- Inject the error message text into the error container
Hint text should be programmatically associated with its related input so that it gets announced by screen readers when a user focuses on the field. This is done by attaching
aria-describedby to the related input and pointing it to the
id of the hint text container.
An error message and hint text will display upon submitting the following form if the requirements aren't met. In this case the requirements are that the field cannot be left blank. The error message and hint text will both be visually rendered and also read by a screen reader if one is in use.
Without an error
<form> <label for="name"> Name </label> <input type="text" aria-describedby="name-error hint-text-name" id="name" aria-required="true" /> <p id="hint-text-name"> Enter your full first name and not a nickname. </p> <div id="name-error" aria-live="polite" role="alert"></div> <button type="submit">Submit</button> </form>
With an error
<form> <label for="name"> Name </label> <input type="text" aria-invalid="true" aria-describedby="name-error hint-text-name" id="name" aria-required="true" /> <p id="hint-text-name"> Enter your full first name and not a nickname. </p> <div id="name-error" aria-live="polite" role="alert"> A name is required. </div> <button type="submit">Submit</button> </form>
aria-describedby can take multiple space delimited ID references, so you can associate both hint and error elements to one field.
What does the research say?
Careful form design has a huge impact on the speed with which users can understand and accurately complete a form. Usability problems on forms really hurt business. When forms follow basic usability guidelines, completion time decreases significantly and users are almost twice as likely to submit the form with no errors on the first try. Follow established recommendations for website forms usability:
- Keep it short.
- Visually group related labels and fields.
- Present fields in a single column layout.
- Use logical sequencing.
- Avoid placeholder text.
- Match fields to the type and size of the input.
- Distinguish optional and required fields.
- Explain any input or formatting requirements.
- Avoid Reset and Clear buttons.
- Provide highly visible and specific error messages.
When it comes to form fields:
- Place the label closer to the associated text field than to other text fields.
- Group together related fields.
Internal research shows that users prefer their information to be saved as they complete a form, and would expect to be able to pick up where they left off if interrupted. Allow customers to return to a claim form in progress to complete and submit, or clearly state that a customer’s data is not being saved pre-submission. Users also desire chat capabilities or a contact number on the page in case they have problems completing a form.
Only ask for contact information when necessary, and make it clear what to expect once a form is submitted. Some users are hesitant about entering personal identifying information, especially if it’s not clear how it will be used. Some users are more open to providing an email address than a phone number.
Primary Sources (Cigna User Research Studies)
These sources are internal studies:
- Designing Usable Web Forms — Empirical Evaluation of Web Form Improvement Guidelines (Seckler, M. et al, Proceedings of the 2014 annual conference on Human factors in computing systems (2014), pp. 1275-1284)
- Website Forms Usability: Top 10 Recommendations (Source: Kathryn Whitenton of Nielsen/Norman Group)
- Form Design Quick Fix: Group Form Elements Effectively Using White Space (Source: Marieke McCloskey of Nielsen/Norman Group)
- Creating Usable Online Forms (Usability.gov)