Accessibility for inactive buttons and form controls

Last year I worked on outlining internal design accessibility recommendations for forms. Part of this work was to decide on the treatment of inactive buttons and form controls since they can be confusing and unhelpful. We found that we needed messaging to make it clear to users why an action isn’t available. Currently, Web Content Accessibility Guidelines (WCAG) recommend that inactive buttons be accompanied by messaging to say why they are inactive, but the approach for providing that messaging is open to interpretation, so there are no clear guidelines for how to provide the messaging to make inactive buttons more accessible.

Forms that can’t be submitted often don’t make it clear why they can’t be submitted. A common approach you might see is to use an inactive submit button at the end of the form, but these are often not accessible. They have low color contrast and don’t tell users why they are inactive. Today there are several ways you can make it more clear why a form can’t be submitted:

• Adding inline validation or error messaging to individual form fields
• Including form instructions at the top of the page
• Marking fields as required

The goal of my research was focused on providing messaging for inactive buttons and conditional form controls. I wanted to identify the most accessible and usable way to surface this type of messaging. I learned that the most accessible and usable approach I tested was to make the button clickable and surface error messaging when clicked.

Example of form field

Methods

I compared the usability and accessibility of different options through a task-based approach. I split the tasks into two sections:

1. Testing messaging options for inactive buttons, such as submitting a form, or taking a batch action on a list view.
2. Testing messaging options for inactive or conditional form controls.

Recruiting

Finding participants for this study was difficult because we needed to test this with users that have disabilities and are using assistive technology. Our existing users do not have a way to self-identify as such, so we used an outside vendor called Helix Opportunity to recruit participants. We recruited 10 participants. The participants recruited were from many different backgrounds and using many different assistive technologies, including trackball, keyboard only interaction, JAWS and VoiceOver for Mac, and magnifying to 900%.

Research Plan

For the first part of this research, I tested three options for providing messaging when a button is inactive. Each of these options was tested on both a form submit button and a list batch action button.

For the second part, I tested three options for providing messaging when an individual form component is inactive or not available.

First Part

Option 1: Adding messaging as helper text below a button or button group

(Left) A feedback form showing helper text below the “submit” button to show why it can’t be submitted. (Right) A list view showing helper text below a set of buttons to explain why actions can’t be taken.

Option 2: Adding an error message to the top of the page when users click on the button

(Left) Feedback form with an error message at the top of the page, indicating that the form can’t be completed because some required fields were not filled. (Right) User list view with error message at the top indicating that actions can’t be taken until objects are selected in the list.

Option 3: Adding form instructions at the top of the page

(Left) A feedback form with instructions to complete all required fields before submitting. (Right) A User List view with instructions at the top of the page below the title explaining that objects in the list must be selected before actions can be taken.

Second Part

Option 1: Adding helper text below inactive form controls

A notifications form showing three checkbox options under a toggle switch set to “on”. The toggle switch set to “off” shows no options.

Option 2: Showing or hiding conditional form controls

A notifications form showing three checkbox options under a toggle switch set to “on”. The toggle switch set to “off” shows no options.

Option 3: Alerts for inactive form controls

A notification form showing an alert below each section in the form not selected to indicate why the options below it are not active.

How we built it

If you’ve ever done accessibility user testing before, you may know that design prototypes can’t be navigated using assistive technology. This was, at first, a big setback, but I was able to get an engineer on the VMware Clarity team to build the prototype using real Clarity components. This prototype was set up with the task of finding the messaging for each option that outlines why the user is unable to complete an action. The testing was done remotely over zoom with participants sharing their screens to show what they are doing.

Scoring

I scored the tasks for each participant on a 0–2 scale.

• 0 = not able to complete the task at all
• 1 = participant completed the task, but it took a while, or they tried several other things first
• 2 = participant completed the task quickly and with no issues.

A table showing scores for each task for a total of eight participants.

Results

Primary findings:

Participants overwhelmingly accomplished the tasks more easily when they received an error message for the first half of the test (submitting a form and taking actions on a list of items). There were several reasons for this being the best option:

• When an alert was used, 75% of users were able to find the messaging in the inactive button research, and 100% were able to find the messaging in the conditional form controls research.
• If they missed any inline error messages, an alert on submit was a straightforward way to call out which ones they missed.
• They no longer had to read the entire page to try and find the messaging because for sighted users, it was easier to find, and screen readers would also read out the error message automatically.
• The page shifts down when the error message appears, so if a sighted user was clear at the bottom of the page, they might see a difference right away and use that to indicate that there is an error.
• Participants performed better with helper and error text in the second half of the study (for inactive form controls) but overall did not mind the toggle switch approach either

Secondary findings

• Only two participants ever found the helper message below the button, and even then, it took much longer.
• One user mentioned that using a toggle switch component is confusing for them when the label changes based on the status of the toggle.
• Participants dislike inactive buttons because if they are inactive, they must go through the whole form to find out what is missing.
• Finding the link in the zoom chat after having shared their screen was difficult for most of the participants (probably because the options all move). In a couple instances, I emailed the link to them instead to make it easier to get to.

Conclusion

For inactive buttons or form controls, it’s most preferred that we use a combination approach: include good form instructions and allow users to click on the inactive button to surface messaging to show exactly what they missed.

For inactive form controls, users generally didn’t mind the show/hide column but did prefer to have messaging to tell them why an action is unavailable if it is being shown on the page.

What’s Next?

Now that we have research for a preferred solution, the next step is to implement the solution and socialize it with other VMware teams. This is a solution I’ve been able to implement in a few areas of one product already.

Including good form instructions and surfacing messaging to show what users missed will create a more accessible experience.