Form Accessibility Guidelines
VMware
Provided a consistent way for designers and engineers to address accessibility tickets related to form controls, behavior, and functionality.
Role: Lead for planning, design, and research
Time frame: 6 months - 1 year
The Goal
Establish and share out company-wide guidelines for accessible form design.
Challenges
Gaining Alignment
Worked with several different VMware product teams to identify use cases to cover
Needed to align with the accessibility team on all guidelines
Research Participants
User research recruiting had to be outsourced due to the need to test with disabled participants using assistive technology
Testing had to be done with an actual built set of forms instead of a design prototype to work with screen readers
Adoption of Guidelines
Shared the guidelines at multiple levels to ensure all designers knew about them
Answered questions from designers as needed
Tested the usability of the guidelines with designers on other teams
Design Process
Requirements
Formed by collaborating with accessibility team and design teams
Design
Showcasing good and bad examples of form accessibility
Documenting relevant use cases for designers
Validation
Internal validation with accessibility team and other designers
Usability testing with participants that have disabilities.
Shareout
Presenting guidelines to design leadership
Presenting to all design teams
Designing Guidelines and Examples
We started by outlining existing form patterns throughout each VMware product. We then outlined whether each pattern met accessibility recommendations, and why or why not. This was a good starting point for identifying what recommendations would likely need to be put into writing.
Based on the examples and guidelines related to each use case, we documented the most accessible way to handle each scenario.
Lastly, we documented all of this in a detailed, searchable Confluence page stored in the Design team Confluence space. This way, it would be available to all designers at the company.
Designer Validation
Next, we tested out these guidelines by having other designers at the company review them to check whether each point was clear, whether there was any difficulty searching for specific patterns, or whether there was a use case we hadn’t identified yet.
User Testing
There was one specific case that was not covered by WCAG (Web Content Accessibility Guidelines) but was strongly preferred by the entire accessibility team. The accessibility team was very against the use of disabled or inactive buttons as a design pattern because it doesn’t indicate to users why the button can’t be clicked.
For this case, I created a research plan, worked with an engineer to build an accessible click-through prototype, and recruited users with disabilities through an outside vendor. I designed the study to test through 3 different ways of offering messaging for why an action can’t be taken.
Showing an error when users click the button
Adding helper text below the button to explain why it’s inactive
Adding form instructions saying that the form must be completed to submit
Top Research Insight
75% of participants found the messaging when they received an error on click. This is in contrast to 20% finding the helper text and 30% finding the instructions.
Delivery
I presented these guidelines to design and architecture leadership teams at VMware and then to the overall design team. I also wrote and shared out a Medium article with my research findings. These guidelines are still used today, and I still receive questions related to design accessibility.
