Structuring accessible forms

On 28 September 2021, I was a guest on Ben Myer’s Twitch stream where we demonstrated best practices for accessible forms. Following is the example code and an explanation of what we covered.

See the Pen Accessible Forms by Rachele (@racheleditullio) on CodePen.

Creating our form fields

The two basic parts of a form field are its <label> and <input> elements. We semantically link the two by

  • Using the <label for="uniqueID"> attribute which matches the <input id="uniqueID"> attribute; or
  • Making the <input> element a child of the <label> element

Doing so allows screens readers to announce the field’s <label> when the <input> gets focus. It also enables the <label> as an additional hit area when using the mouse to focus on an <input>, which is especially useful for checkboxes and radio buttons.

We also need to specify the type of input using the <input type=""> attribute. Putting those together, we have a basic form with one text field and two radio buttons.

<form>
  <label for="name">Cat's name</label>
  <input type="text" id="name" name="name">

  <label><input type="radio" id="yes"> Yes</label>
  <label><input type="radio" id="no"> No</label>

  <button type="submit">Send</button>
</form>

A note on combo boxes

As much as possible, use native HTML <select> and <option> elements to create an expandable list of single-select options.

...
<label for="markings">Cat's markings</label>
<select name="markings" id="markings">
  <option value=""> select an option </option>
  <option value="solid">Solid</option>
  <option value="bi">Bi-color</option>
  ...
</select>
...

Grouping similar fields

Our radio buttons are labeled ‘yes’ and ‘no,’ but what are they for? We need to use the <fieldset> and <legend> elements to provide that semantic meaning. The <fieldset> groups the related form fields while the <legend> provides a name for the grouping. These are most often used for checkboxes and radio buttons but they can be useful for grouping other related fields, e.g. Shipping address.

Since radio button options may have similar names, group like radio buttons with the name="groupName" attribute. Keyboard users move between radio buttons in a group with the arrow keys.

...
<fieldset>
  <legend>Is your cat altered?</legend>
    <label><input type="radio" name="altered" id="yes"> Yes</label>
    <label><input type="radio" name="altered" id="no"> No</label>
</fieldset>
...

Marking required fields

Let’s create a required field for collecting email address with <input type="email">. Provide a visible indication of the required field for sighted users, such as an asterisk, but hide it from assistive technology using the aria-hidden="true" attribute.

Then there are two attributes we can use to programmatically define required fields: aria-required="true" and required.

Use one (not both) of these attributes to ensure required fields are conveyed appropriately to assistive technology. Screen readers will say required when announcing the form field name, role and state.

...
<label for="email">Your email<span aria-hidden="true">*</span></label>
<input type="email" id="email" name="email" aria-required="true">
...

The required attribute provides a first layer of form validation on submit. Many modern browsers will not submit a form with empty required fields and will even provide a visible error message.

a requried field in a web form that is empty and displays the message please fill out this form field.
Required field in Firefox for Windows

However, user agent error handling is not dependable as these error messages are not always announced or available to assistive technology; they can’t be styled or resized; and they are not persistent.

Handling errors

It’s important to provide a list of all errors at the top of the form or provide them in-context of the field in error. We can programmatically link the error message with the form field using the aria-describedby attribute.

...
<input type="email" id="email" name="email" aria-required="true" aria-describedby="error-email">
<p id="error-email">Email format email@domain.com</p>
...

When assistive technology users focus on the email field, the error message is announced along with the name, role and state of the field.

Verifying data

In addition to marking fields as required for assistive technology, we also have to indicate if the data entered into each field is valid. All required fields should also include the aria-invalid="true" attribute. Update this to “false” when it passes validation.

It’s also an accessibility requirement to make entering valid data as easy as possible. HTML has a set of autocomplete values that we need to use for any fields collecting personal information that might already be stored in the user’s browser. Email is one of these fields.

...
<input type="email" id="email" name="email" aria-required="true" aria-describedby="error-email" aria-invalid="true" autocomplete="email">
...

We can further enforce data validation in HTML for fields that aren’t necessarily required by using the pattern attribute that accepts a regular expression. Let’s create a field for collecting birthday with a required format of mm/dd/yyyy.

...
<input type="text" id="birthday" name="birthday" aria-describedby="help1" pattern="^\s*(1[012]|0?[1-9])\/(3[01]|[12][0-9]|0?[1-9])\/((?:19|20)\d{2})\s*$">
<p id="help1">Birthday format mm/dd/yyyy</p>
...

This pattern matching prevents the form from submitting if the data entered does not match the specified pattern.

Conclusion

I hope you found something to make your forms more accessible. I like forms because they have such a strong semantic structure. There are a lot of things to get right but it’s pretty straightforward what “right” means in this context: Make sure anything that is conveyed visually is also conveyed to assistive technology, including the states of form fields.

Disability Independence Day

The Disability Rights Movement in the United States is a difficult and ongoing fight. From inaccessible buses and buildings to today’s inaccessible websites, the disability community has a long legacy of protesting for equal access. On March 12, 1990, more than 1,000 disabled people gathered at the US Capitol building in Washington, DC, to advocate for the Americans with Disabilities Act (ADA).

The path to reach the members of the House, where ADA legislation had stalled, was up 83 stone steps. For dozens of people with mobility impairments, this stairway exemplified the never-ending barriers that cause disability. Under the social model of disability, when people have to navigate an environment filled not only with physical barriers but social and communication barriers that limit access, this results in disability.

In a bold display, more than 60 activists left their wheelchairs and mobility devices and began making their way up those 83 stone steps; it became known as the Capitol Crawl.

A disabled man on his knees and a disabled woman scooting ascend the US Capitol steps.
Members of ADAPT during the Capitol Crawl / Photo credit: Tom Olin

The sight of people literally dragging themselves up stairs to demand equal accommodation left an indelible image on the US public and lawmakers. The Capitol Crawl is credited with being the most influential event to lead to the signing of the ADA on July 26, 1990. Today, we celebrate this landmark piece of legislation as Disability Independence Day.

Accommodations—like curb cuts, ramps and elevators—that make the environment easier for all people to navigate daily life are just some of what the ADA promises. As digital creators, we have a responsibility to extend these rights online when people use websites, kiosks and mobile applications. Since the Web was not around in 1990, it is not mentioned in the ADA, but many accessibility lawsuits have ruled that Title III of the ADA applies to digital commerce. If you want your product to be innovative and inclusive, design with disabled people in mind.

Five ways to include d/Deaf users in your designs

More than one in twenty people—an estimated 430 million people—experience disabling hearing loss according to the World Health Organization’s 2021 fact sheet on deafness and hearing loss. Some are functionally deaf, having little to no hearing. Others are culturally Deaf with a preference for communicating with sign language. A lack of public awareness and familiarity with d/Deaf people’s needs is still common, which can lead to oversights in the designs of smart devices, web content, mobile apps and communication styles. Let’s look at five ways that we can improve online experiences for d/Deaf users.

Read the full story on the TPGi blog.

a small smart speaker lit up to indicate its listening