HomeHome

Web Forms for Everyone 

What designers & developers can do to make their forms accessible and improve everyone's user experience as consequence.

#3 · · read

Since the beginning of the web's history, web forms have been the primary interface between users and online services. Designing and building web forms that are accessible by users with diverse abilities is therefore paramount.

Everyone loves web forms

As a UX Designer, I love designing web forms. I love to create clever designs that are not just easy to use but can be accessed by everyone. What I love particulary about designing web forms is that they offer so much room for accessibility & usability tweaks.

People with disabilities rely on designs that consider their unique circumstances. Users with visual impairments such as blindness or cataract can use screen readers to fill in forms. If forms are not accessible, they might not be able to properly perceive input controls and labels. But also people who have a type of color blindness are negatively affected by bad form design that only uses color to communicate errors. People affected by the most common form of color blindness (red-green) are not able to distinguish between reds, oranges and greens. Now guess which color is mostly used to indicate errors in forms?

While I love forms and I can acknowledge that I diverge from the norm, the average population of the internet tends to hate web forms. A personal history of bad form design have done its part for users to avoid forms at all costs.

Are you familiar with forms such as this?

  • forms that are excruciatingly long
  • forms that ask you to open a dropdown list to answer a yes/no question
  • forms with input fields that use placeholder text instead of labels, so you might forget the data you have to enter in the second you start typing
  • forms that show validation errors while you are in the middle of entering data, e.g. input fields that ask you to enter an email address
  • forms that crash, respond with a generic error ("an error occured") and ask you to enter all your input AGAIN

I understand the frustration that people have with web forms. I have them too. But my job allows me to fix everything that's wrong with forms.

I'm sure I can make you love web forms too (especially if you are a designer or developer). Just read on if you want me to try.

Use expressive labels & easy language

To begin with, using expressive labels for input fields increases the form's readability. This way, users are able to quickly scan and understand the form. Users shouldn‘t have to think about what is being asked of them. Instead, use labels that are brief and to the point, written in the user's language, not in officialese.

In forms, the <label> element is used to label input elements.

<label>First name</label>

Connect labels and inputs

Next, it is essential that labels are programmatically connected to their corresponding input fields. Input elements need accessible names so that assistive technologies can make sense of them.

The label element can be connected to an input element by referencing on its HTML ID. If there is no connection between these elements, screen readers will not announce the name of the input, but only the type of input (e.g. "edit text" for a text field in the case of macOS's native screen reader VoiceOver).

Use the "for" attribute to connect labels and inputs.

<label for="firstname">First name</label>
<input type="text" id="firstname" name="firstname">

A nice side effect of this connection is an extension of the input’s touch target size. As soon as label and input are connected, a click on the label itself will focus the input. No need to click directly into the input field.

Make input hints accessible

Some inputs require additional information, such as descriptions of the data users need to enter or expected input formats. This information is usually shown below or next to input fields. If you properly associate this description with the respective inputs, screen readers will be informed about this as soon as the input element receives focus. This beaufiul behaviour can be achieved using aria-describedby.

<label for="birthday">Date of birth</label>
<input type="text" id="birthday" name="birthday" aria-describedby="birthday-format">
<p id="birthday-format">DD.MM.YYYY</p>

Avoid placeholder text

We often come across forms that show no labels for input fields but use placeholder text for this purpose.

The problem with placeholder text is that it isn‘t a proper label. It disappears as soon as the user starts typing. In that moment the user might forget what they were supposed to enter. This becomes especially frustrating, when placeholder text is used to show the expected format of an input such as a date format (e.g. DD.MM.YYYY). In order to reveal the placeholder text again, users have to delete their typed input, which is very annoying.

Always show labels for input fields. Don't rely on placeholder text.

Indicate required input fields

In order to distinguish required from optional fields, required fields are often indicated using asterisks. This lets users quickly scan forms for input fields that have to be filled in. In the sense of transparency, it is recommended to display an explanation of this pattern as part of your form (such as "* marks required fields").

Another approach would be to put the word "required” at the end of the label. Optional fields need no such indication.

In order to programmatically convey this information to assistive technology, use the required attribute on the input element. Screenreaders will announce required input fields when they receive focus.

<label for="firstname">First name</label>
<input type="text" id="firstname" name="firstname" required>

Use semantic input types

Did you know that HTML supports 22 different input types? While the most common and most flexible input type is "text”, you should consider the other types for your use case.

Using these specific types can improve the semantics of your form. If you use "number” for example, browsers will display a stepper next to the input. This allows users to easily adjust their numeric input.

<label for="age">Age</label>
<input type="number" id="age" name="age">

Chromium-browsers go as far as restricting user input to numeric values in case that input type is used.

Other types, such as "tel”, automatically show a special keyboard on mobile devices for easier input of numeric values. The same works for type "email”, which shows a keyboard that includes the "@" symbol.

Think about how you can best support users when choosing input types. Using "text" for first and last name is quite obvious. But does entering a birthdate require a date picker?

For dates that users know by heart it might even be frustrating if they have to use a date picker. It is much faster if you allow users to simply put in their birthdates using a regular text input. Of course this will result in more programming logic to validate the entered data.

Is a dropdown list the right input type for a quantity in an ecommerce scenario? I would argue against it, since the user is required to open the control first before selecting a value (one extra click) and the allowed values are hidden behind a control. Type "number" definitely is a better fit.

Make your form keyboard accessible

Talking about semantics: semantic HTML is key to keyboard accessibility (dad joke alert). Users expect that every interactive element in your form can be accessed using the keyboard.

If you refrain from using <div>s you get this behaviour out of the box. Native HTML elements, like <input>, <a> or <button> all have an implicit tabindex attribute. If you really, really, really have to use a <div> then make sure to add it to the tab sequence.

<label for="my-custom-checkbox">Check this out</label>
<div id="my-custom-checkbox" role="checkbox" aria-checked="false" tabindex="0"/>

But of course, this should only be a last resort.

Forms tremendously benefit from keyboard accessibility. Isn‘t tabbing through a form with your keyboard much faster than using a cursor? For me personally, this is the default.

Enforce autocomplete

Just think about how many forms you have filled in in your life. Browsers save previously entered form data for the user’s convenience. If you mark up your form fields with the autocomplete attribute, you can make use of this data.

This can be achieved by indicating the purpose of your input fields to the browser using the autocomplete attribute. If you do, browsers will be able to match your field‘s purpose with the data entered into previous forms.

<form>
    <label for="firstname">First name</label>
    <input type="text" id="firstname" name="firstname" autocomplete="given-name">
</form>

Here are some examples of possible values for the autocomplete attribute:

  • given-name
  • family-name
  • email
  • street-address
  • country
  • bday
  • tel
  • ...

This will allow users to fill in your form much quicker, since all the user data might have previously been entered in a different form.

Accessible forms for everyone

Now that we have learnt so much, let‘s take another look at the benefits of building accessible web forms:

  • Expressive labels
  • Increased touch target size of inputs
  • Visible labels and input hints at all times
  • Quickly distinguish required from optional input fields
  • Support users‘ data entry with fitting input types
  • Support users‘ data entry with the keyboard
  • Support users‘ data entry by using previously filled form data

These are all accessibility features (and there is so much more where that came from!). But I think we can all agree that they not only increase support for assistive technologies.

These feature essentially increase usability and improve everyone’s user experience. And they are the reason why I love web forms. And so should you! ✌️

Reply to this post

Share your thoughts in English or German via good old email.

Reply by email

Subscribe to niqwithq.com

I write a personal blog about software, writing, blogging, productivity, travel and the small web.

Subscribe to my RSS feed instead.

No spam ever. Your privacy is my concern.