Creating beautiful, accessible and user friendly forms
Notes from FITC Web Unleashed 2016 presentation by Clarissa Peterson (slides)
Forms are a key way users interact with your website, so making sure they work well will have a big impact on your UX. The simplest forms are the best not just because they’re easier to make (extra questions on a form mean more data you have to clean up), but also because they are easier for your users to complete. If you ask extra questions that you don’t necessarily need for the task you first need to build trust with your users so they feel comfortable providing you with that information. For example, Facebook takes the time to explain to you why they’re asking for your birthday on their sign-up form (even though it’s a lie). In general, you want to pace and build up your forms slowly, e.g. Twitter asks you for your name and email on the first page, and then on the next page asks you to pick a username (a more difficult decision) after you’re already somewhat invested in the process.
Form input types
With HTML5 we know have many more input types:
- date: Some desktop browsers will provide a calendar UI by default. A max possible date can supplied so users don’t something too far off in the future.
- time: Like date, you can set a min and max possible time.
- email: On mobile you’ll get a different keyboard with an @ and . to make it easier to enter your email address on mobile. There is also some built-in validation.
- url: Also gives you a different keyboard on mobile.
- tel: Brings up a number pad on mobile.
- number: The thing to remember about numbers is that not everything that looks like a number is a number, e.g. you should use a text field for credit card “numbers”.
Dropdown and radio buttons
You’ll want to avoid drop downs in generally, but especially when there are only two options. For two options use radio buttons. You’ll want to style the radio buttons in order to give users a larger area to click though. You can do this by setting the radio button opacity to 0, styling the labels, and using the :checked pseudo selector to style the label that has been checked. Sometimes you’ll actually need a dropdown, e.g. a country selector. In these cases you’ll want to place the most likely options at the top, not strictly in alphabetical order. You’ll also want to use loose partial matching to guess at the best possible option depending on what the user’s typed in. A long dropdown list can be divided into categories with an optgroup.
Labels and placeholder text
Label elements are very important for screen readers since screen readers cannot read placeholder text, so make sure you match up your labels to input fields. Placeholders are meant only to give an additional hint about what to write in the field. Once you begin to fill out the form you can no longer see the placeholder to know if you filled in the appropriate information, so only use placeholder text instead of labels only if it’s more important for your site to look pretty than be usable. In the cases where you need to hide the label, use the aria-label attribute on the input element and placeholders. Also note that placeholder text is not dark enough to meet minimum contrast requirements by default, but on the other hand you don’t want to make it darker as that would suggest that the form is already complete. If you style the placeholder text be sure to use vendor prefixes.
Use the required and aria-required attributes to signal to the user that the input filed must be filled out. For forms where most, but not all fields are required it’s easier to indicate which are not the required with an asterix (the convention) than indicating the more numerous fields that are. Keep in mind that not everyone knows what an asterix means, so provide a key at the top of the page with its meaning. Also, you don’t want to just use colour to indicate field requiredness as colour-blind people may not see them.
Creating a password is a commonly problematic part of the website, since requirements for passwords can vary and need to be communicated ahead of time–not just when submitting the form. It’s better to explicit about the requirements than just saying, “you’re password is weak”, which can lead to frustration. You can hide the instructions until the user is focussed on the field if you like, but tell them the rules. Also, provide users with the ability to toggle their password visibility so they can see where they made a mistake, but show the password as only asterixes by default or users think your site is not secure.
The only time instant validation is useful is when entering a user name. In other cases its just frustrating. Give them a chance to fill in their full email address before yelling at them that it’s invalid because it doesn’t include and @ sign. Emails should be validated only after moving off the field, rather than on each keystroke. Fields can be styled by whether they contain valid or invalid information, but try not to just use color to distinguish them.
Do you need to ask?
If you ask about gender, first make sure that you really need that information. If you do, consider having a third category. For example, Facebook later on lets you choose Male, Female or custom which gives you chance to specify the pronoun that you want. On most sites you can simply avoid using pronouns, but on medical sites it’s information that’s actually important to know.