Making webforms accessible
Editor’s Note: To keep the spirit of #a11yTO week alive on our blog, we’re talking accessible webforms.
Meaghan Eleanor is a front-end developer at the Ontario Digital Service. Her goal is to create accessible and visually interesting web experiences for all.
The user problem
A few months ago, our technology team received user feedback indicating accessibility issues with Ontario.ca webforms.
Specifically, the user indicated their screen reader, an assistive technology, was not reading out options to questions through radio buttons effectively.
Radio buttons are control elements that allow users to choose a single option among a set. They are typically represented by small circles, which a user fills in or highlights when selected.
Accessible radio buttons, which are, in part, made by the correct usage of labels, are read out individually by screen readers. This is so that users can hear the list of options available to them.
The user we received feedback from could not answer certain questions required on the webform, because the radio button options were not being read out accurately.
Auditing different webforms
The Ontario.ca team audited a few different webforms both manually using screen readers, and with automated tools, such as Wave, Tenon and WCAG audit report.
Through testing, we confirmed that recent changes to the HTML structure of radio buttons, generated by Drupal’s webforms , was causing accessibility issues for users using screen readers. The HTML for radio buttons was no longer written semantically and, as a result, was not reading out the options correctly.
We considered a few, different solutions:
- Creating a custom module that would build on Drupal webforms and fix existing accessibility issues
- Using a different service altogether to generate webforms such as SurveyMonkey or SurveyGizmo
- A quick fix solution, which would lead to re-structuring the webform content to eliminate the use of radio buttons until a more concrete solution was developed.
Tech community solutions
After doing some research, we learned that the Drupal maintenance team had recently discovered a bug with radio buttons in Drupal webforms. We also learned that a patch had been created, and vetted by the Drupal community, to help fix the HTML structure of webforms.
(Side note: community fixes are amazing!)
Ultimately, we agreed to use this patch as the solution to the problem.
Challenges working with anonymous user feedback
Because the feedback from the screen reader user was submitted anonymously, we weren’t able to contact the user to get clarifying information, including:
- How they specifically use their screen reader
- What version of screen reader they used
- What specifically was breaking down for them
- How we might replicate the issue on our end to test further
This meant that we needed to do a lot of manual testing on our end to try and discover what pain points the user may have experienced.
The importance of diverse networks of user testers
Our research reinforced the importance of user testing and, specifically, testing with users with disabilities.
The developers on our team who were manually testing the webforms did not have any visual impairments, so we had to educate ourselves.
As Nicolas Streenholt, an accessibility consultant and champion notes in his post Should Sighted Developers Use Screenreaders to Test Accessibility:
“A sighted user tends to scan the content on the page “at a glance” — the gaze can jump from right to left, top to bottom, and back. Someone relying on screen reading software gets to see the information in the order it appears on a page — They see the information in a “top-down” fashion.”
The best way to get a user’s perspective, particularly a user with a disability, is to invite them into the design and development process. Individuals understand their lived experiences best.
How we tested for accessibility
Looked for common patterns
We looked closely at outside examples of forms and transactional features, and compared them against Drupal’s webform.
We looked for things like:
- Did the form have a logical order of operation?
- Did the form lay out lists including radio buttons and checkboxes vertically (something generally considered to be best practice for form accesibility)
- Did the form use label tags as click targets?
- Did the labels have attributes that matched the controls?
We recommend this blog post Radio Buttons UX Design by Nick Babich for further reading.
Used an automated accessibility auditing tool
We inspected the page with automated accessibility auditing tools, including Wave, Tenon and WCAG audit report.
While these types of tools typically only catch about 40 percent of accessibility issues, auditing tools are often free and catch errors that cut manual labour significantly. These tools also allowed us to see different semantic elements of the screen that we may not have caught through manual audits, including:
- The order of headings
- The existence of aria labels
- Form inputs that have explicit labels
- The semantic structure of the page
Tested the keyboard navigation
Using tools like NVDA, JAWS & VoiceOver, we asked ourselves:
- Were we able to navigate through the page without falling into any keyboard traps?
- Could interactive features be completed through using our keyboard?
- Is the tab order logical?
Keeping user capabilities in mind
A user should be able to do the following:
- Use the tab key to navigate and activate every interactive element on a page
- Tab through interactive items in a logical order, usually from left to right and top to bottom
- Tab through the site and make sure everything that should have focus, gets focus
- Be notified, or informed of, any changes that happen when completing an interaction (for example, are alerted of any errors, error/validation handling, etc.)
- Follow a navigational order, otherwise known as an information architecture, that makes sense for them
Lessons learned and next steps
Observe users using their technologies on our products.
The more primary research we can do, going directly to the source, the better our product gets.
Investing in accessibility training is important
While not everyone needs to be an accessibility expert, it is important to have accessibility in mind when designing, developing and solutioning. This often requires coaching from experts.
Be accessible by design
Accessibility is everyone’s job and improving accessibility improves clarity.
Develop consistency
Make sure our webforms, and the components that support them all have the same look, feel and functionality.
Thoroughly vet and test third party features
Focus on compliance with any new transactional products.
Be intentional when designing future webform iterations
Consider developing your own module, leveraging what you know already works accessibility-wise with your chosen platform.
User research at the start of a project
Can’t emphasize this enough!
Final thought
Think about accessibility at the origin of your project. Trust me.
Additional reading
Looking for more information? Here are some resources I pulled together.
- List of semantic HTML5 elements and their support capabilities across browsers
- Design Better Forms by Andrew Coyle
- Web Accessibility tips from the University of Guelph
- Testing with assistive technology from the Gov.UK
- Screen Readers & Browsers! Which is the Best Combination for Accessibility Testing? By Raghavendra Satish Peri
Get in touch
If you are working on a team that is undergoing the design or development of accessible webforms, comment below!
