Creating accessible input errors and help text
As we approach Global Accessibility Awareness Day, I thought I’d share some of the work I’ve been doing in Pulsar to simplify the process of making inline form help and error text accessible.
Form helpers
If you’re familiar with the Pulsar design system or the Jadu Continuum platform it powers, you might know that the majority of our UIs are built using the Twig templating engine. Pulsar provides developers with various Twig “helpers” to make building UIs faster, more consistent and remove some of the complexity developers may face when building UIs.
Here’s an example of a form.text helper in use:
Which, when served to a browser, would output:
And look like:
Using helpers to build UIs in our software gives us a single point of truth, in that, if we ever needed to change the markup or add additional attributes then we could do that in the Pulsar framework and the change would roll out across all UIs in our software ⚡.️ It also gives our developers a common API for the user interface, they don’t need to know how to mark up an error message, they just pass the error text and the helper takes care of the rest.
You can read more about Pulsar’s helpers in the Pulsar docs.
How does it sound? 🔈
Lets run our example through a few popular screen readers to see how it sounds. I’m going to test in JAWS and NVDA on Windows, and Voiceover in MacOS — which according to a WebAIM, cover the 3 most popular.
Results
When the field gains focus:
JAWS says: “Name, edit, type in text”
NVDA says: “Name, edit, blank”
VoiceOver says: “Name, edit text… You are currently on a text field, to enter text in this field, type”
As you can see, none of the screen readers read our help or error text 😔
ARIA to the rescue!
In case you haven’t already spotted the issue, the generated markup is missing some ARIA magic to link the help and error text to the input. Previously our helpers relied on the developer building out the UI to add the necessary ARIA attributes to make things work as needed.
In our next release of Pulsar all form helpers will automatically add any ARIA attributes required. Now the developer won’t need to worry about extra options/attributes and the end user gets accessible help and error text by default 🎉
Lets take our last example and throw in our new helper updates and see how they read.
As the real work is done behind the scenes, no helper changes are required.
The generated markup does look a little different though, can you spot the differences?
Screen reader results
Now, when the field gains focus:
JAWS says: “Name, edit, invalid entry, please enter your full name, your full name, including any middle names, type in text.”
NVDA says: “Name, edit, invalid entry, please enter your full name, your full name including any middle names, blank”
VoiceOver says: “Name, invalid data, edit text, please enter your full name, your full name, including any middle names”
Our help text, error message and the fact that the field is in an invalid state is now read to our user 🎉
As you can see in the generated markup, we’re now linking the input to the help and error messages with aria-describedby and also adding the aria-invalid="true" state to the input to signify the inputs data is invalid 💪
Stay tuned for more
Taking advantage of our UI helpers in this way allows us to deliver components that are accessible by default, our developers don’t need to do anything, as soon as we publish this change the UIs across our software will get an improved experience for assistive technologies automatically.
I’ll be posting more accessibility-related stories in the coming months as we roll out more accessibility improvements in Pulsar.
