Whenever I do a full audit for a website, I have almost 40 individual, highly granular, form-related checks. Those checks can be boiled down to the following 6 high level goals.
1. General Structure
Check that the form has a logical structure, with headings and subheadings used to group related fields and information. Ensure that the types of fields in the form are appropriate for the types of information being requested. For example, that when input is expected to be a short string of arbitrary text, that <input type="text"> is used whereas when an email address is requested that <input type="email"> is used. Selecting the right form field for the expected input is important for both usability and accessibility.
2. Field labels and instructions
Next, make sure that each form field has a clear label and that the label is explicitly associated with the field. The simplest test for this is to click on the text for the label and, if the associated field gains focus, the association is explicit. Use caution, however, because this isn’t a guarantee that the accessible name for the field is correct or sufficient. Some developers will try to sprinkle ARIA on a form to make it more accessible but actually do it wrong. This is why I tend to favor using a screenreader when testing forms. With a screenreader turned on, tab through the fields to listen to the field labels. Do they make sense? Are they clear? Are any relevant formatting constraints disclosed? Are the constraints announced as part of the label?
3. Keyboard navigation
Ensure that all form elements can be accessed and filled out using only the keyboard. This is among the easiest things to test for: simply use only your keyboard to navigate between fields, enter content, and make selections. Usually the form will pass quite easily when the form is made using native HTML, but when the form uses custom components for things like <select> elements, radio buttons, or checkboxes, things can be hit and miss.
4. Tab order
While testing the keyboard accessibility, also be mindful of the tab order. Most forms will pass this test because most forms on the Web these days use a single-column layout with fields in a vertical layout, each new field below the one prior. Be sure to pay extra attention to any form that is laid out in multiple columns. There are still lots of forms out there laid out using tables, and those can often have odd tab order. Testing this is easy: Simply ensure that as you tab, the fields gain focus in an order that makes sense in consideration of what information is being requested.
5. Field focus
While testing keyboard accessibility, ensure that the focus indicator is obvious. While the wording of the relevant WCAG SC, “Focus Visible”, isn’t terribly prescriptive in terms of what it takes to satisfy this requirement, my own guidance is to say that the default focus indicator from the browser is often insufficient. To quote Luke W: Obvious always wins and this is especially true when it comes to focus indication. As you tab around the form, the field in focus should be obvious.
6. Error handling
Finally, test the form’s error handling. Doing this is pretty easy: All you need to do is intentionally submit incomplete or invalid information. From there, determine if error messages are clear and easy to understand. Do the error messages clearly convey what information was missing or wrong? Given the messages – and presentation of those messages – is it likely that a user will be able to recover from errors?
By thoroughly assessing your form’s conformance to these six high-level goals, website owners can ensure that their forms are well-structured, accessible, and user-friendly. Implementing these best practices will lead to improved usability and a better overall user experience.