Forms

Names of the fields

Form fields need to have accessible names. You can use <label> element, or attributes 'title', 'aria-label', or 'aria-labelledby'. The ARIA labeling will make them visible to screen readers but a sighted user will not see this information. The most accessible and easiest option is to display visible labels. If done correctly, these are seen by everyone.

Error messages

With forms, it is essential that you don't convey information with solely color. Very often an error message will be displayed with red and the normally gray input field border will be changed to red. This kind of information will be completely hidden from some users.

Consider indicating errors by adding or changing something structural. For example, add an icon to the error message. Or add a border next to the error message.

Also, remember to always have meaningful error messages. If the error is caused by the user adding content in the wrong format, consider instructing the user of the correct format before an error occurs. And if the error occurs, provide as much information as possible. "Wrong format" is not informative enough. And if possible, your forms should fix the formatting issues, don't make your users do it.

Error prevention

For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: 

• Reversible: Submissions are reversible.
• Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
• Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

WCAG 3.3.4

The Understanding Success Criterion 3.3.4: Error Prevention (Legal, Financial, Data) page offers good information and techniques for making sure your forms are not causing problems for your users. The page lists sufficient techniques for each different situation, for example, if an application causes a legal transaction to occur or if an action causes information to be deleted.

One advisory technique that is listed is providing client-side validation and alert. And another good practice is to provide your users with feedback also when data is submitted successfully. I've heard from an SEO expert that having a separate thank you page is better or easier than having a message displayed with the form because that can easily be tracked in analytics. No matter what way you provide the feedback, remember to check that the feedback is presented correctly for screen reader users as well.

Often made structural mistakes

I've been doing accessibility audits for about a year now. Here are some of the more common mistakes I've seen on various websites.

Select element

<select> elements are often left without a visible (or non-visible) name. And quite often a might have been used but the 'for' attribute is missing. Or sometimes a title text has been added but it's just a regular paragraph or title. Having a label for each select is good practice.

Also, especially with custom implementations, the default selected option is often left without a 'selected' attribute. The attribute should always be added.

By the way, there is a nice <optgroup> element for you to use when you have grouped options in a select.

I have created a simple demo about the usage of <select> elements on my accessibility info site. Check out the demo relating to WCAG criteria 4.1.2.

Text next to an input - not as a label

One quite interesting thing I've seen is that there actually has been added some text next to an input field that is clearly meant to be the label of the field. But the texts haven't either been inside label elements, or the label elements might not have been attached to the form fields. So if you can add visible labels, remember to do them correctly.

Also, if you copy and paste some form fields, make sure you change the field the label is attached to. These kinds of mistakes cause some real confusion for people who use screen readers.

Placeholders as labels

Often a placeholder is used in place of a label. This is not okay because the placeholder is not a label. The placeholder should be a short hint that describes the expected value of an input field. For example, a sample value.

A placeholder disappears as soon as the field has content, so if the placeholder is used in place of a label, this is quickly very problematic. Imagine getting an error in a field. To see the "label", you would have to clear the field to see if you understood the field purpose wrong. Not very user-friendly. Especially if combined with uninformative error messages.

Radio buttons and checkboxes without legends and fieldsets

You should have <fieldset> and <legend> elements around radio buttons and checkboxes. This is not required but if these elements are not used, screen reader users are often left wondering what the options are about.

The <fieldset> element provides a container for related form controls. And the <legend> element is a heading to identify the group.

Fieldsets used for styling only

The <fieldset> element can easily also be used for styling. If you do this, remember that the <legend> shouldn't be nonsense. I've seen headings like 'fieldset 1' and 'fieldset 2'. Give them proper names. If you cannot figure out a good name, then use, for example, <div> elements for styling. You shouldn't misuse elements.