Three Essentials of Form Accessibility

Accessibility is sort of like security in web development - while there might be roles dedicated to the subject in an organization, it's really everyone's responsibility to build and maintain the application correctly. It also includes employing both broad strategies around sound app archicture, as well as specific tactics in the code itself.

There are easy, basic ways to make your forms more accessible though. And a lot of it ends up making your own code easier to read and reason through.

Use Semantic HTML

AKA - don't overuse divs! A big part of writing accessible form code is simply to abide by HTML standards that make your markup more descriptive in general - more descriptive to the programmer but also the screen reader.

For example, it's possible to make both the following forms present and behave in exactly the same way, but the second form, which uses semantic HTML tags like <label>, is infinitely better than just grafting style rules on to a plain <div/>, like the second one does.

1. Antipattern

<form>
  <div class="label">Full Name</div>
  <input type="text" name="name" />
  <div class="label">Email</div>
  <input type="email" name="email" />
  <button type="submit">Submit</button>
</form>

2. Semantic

<form>
  <label for="name">Full Name</label>
  <input type="text" id="name" name="fullname" />
  <label for="email">Email</label>
  <input type="email" id="email" name="email" />
  <button type="submit">Submit</button>
</form>

Semantic HTML for forms is great for a lot of reasons - it's more readable, for one - but it also tells screen readers what parts of the markup to pay attention to and how to read them.

Add Appropriate aria Labelling

There's a lot you can do with aria (fun fact: "Accessible Rich Internet Applications" standard), but since we're focusing on building an accessible form foundation, we'll cover the two biggest for forms - aria-label and aria-describedby. Other aria tags like aria-role are nice for forcing screen readers to understand a particular element as a button (or link or checkbox or whatever), but are more commonly used in non-form cases.

aria-label

The aria-label tag is used to apply a string label to an element that doesn't have text. It allows a screen reader to understand an element's label even if there's nothing else to go off of. For example, a typical "X" button used to signify a close action might not have the actual text Close readable anywhere. So that aria-label='close' ensures the button icon is interpreted correctly by assistive technologies.

aria-describedby

MDN puts it succinctly "The aria-describedby attribute is used to indicate the IDs of the elements that describe the object", not just in forms but in widgets with related text elements too, adding more information in a description than would typically be associated with the one or two word label. Note: not just in forms, but especially for form markup.

Use Visuals in Error Messages

A big part of any bug fix - and lack of accessibility features is a bug - is evaluating the priority along the axes of severity and prevelance. If a bug is severe, but only exists for a wonky user flow or hyper-specific edge case, that's going to be less important than some visual glitch that - although a workaround exists - affects the majority of users in production.

This school of thought very much applies to any issue related to deficiencies perceiving color. About 8 percent of men and .5 percent of women suffer from color blindness according to the Amercian Optometrists Association, making it a relatively common disability - and web accessibility issues around it particularly impactful.

One such issue is making sure errors aren't indicated solely by color. This is important because it's such a common practice. But of course usingly only color is an awful indicator for the colorblind, which is why errors should also be indicated by symbols.

Wrong

A color-impaired person could misread this error state without the info denoted by the color:

email is required

Correct

Though you need to add the visual indication, there's no reason you can't still leverage the semantic meaning of a red error:

⚠ email is required

Also Correct

Another valid option is to actually use the word Error somewhere in the message so that there's another clear indicator besides color.

Error: email is required

The common thread is obvious - relying on color to indicate a form state is difficult when all users don't experience color the same way. This idea is bigger than just error messages of course: it also comes into play when discussing optimal color contrasts - important, but a little too general for our tastes.

Wrapping Up

There is an entire world of accessibility outside of forms, and wayyy more for forms than we've delved into here. I've tried to just cover the biggest and most low-hanging of fruit, things that are so simple to incorporate you really have no excuse 😁. If you're interested in learning more, browsing the Mozilla Web Docs is a great reference that also includes larger guides and "learning paths" related to accessibility and web development.