As the practice of testing as a team activity continues to be embraced, testers and developers often collaborate on implementing custom attributes or selectors to improve resilience and maintainability in their automated tests, but can sometimes miss an opportunity to improve testability and accessibility together without extra effort.
WAI-ARIA describes ways to make rich web applications more accessible to people with disabilities. HTML attributes are part of those recommendations and aria-label is a particularly interesting one because it contains the text that will be read aloud to a user via an assistive device such as a screen reader. In other words, aria-label attributes inform the UI a blind user hears.
Using custom data- attributes is a common practice in front-end automation. Quite often, they contain some sort of metadata about the element — data that could instead be expressed as an aria-label attribute. The benefit to test automation is still there, but you get bonus points for better accessibility, too.
Date pickers can challenging to automate because your tests need to do things like “click tomorrow” or “click two weeks from now” rather than on specific dates so they keep working day after day. Let's take a look at how an aria-label can be used for this purpose in an automated test.
Here are some great examples of aria-label attributes from date pickers on three top travel sites:
aria-label="Choose Tuesday, March 26, 2019 as your check-in date. It's available."aria-label="March 26"aria-label="March 26, 2019"
I wrote a few lines of JavaScript that makes working with these accessibility-aware date picker controls easy. It returns a date x days from now that can be formatted or translated according to a desired locale, e.g. March 26 or 26. März 2019.
From there, it's then easy to find elements, or create assertions in mabl using selectors as simple as [aria-label=] or [aria-label=]. These sorts of dynamic variables make ideal JavaScript snippets.
Now, it can be unwise to couple your tests to presentation data, like text, so consider your specific application and remain mindful of achieving stable element identifiers. Since the calendar is unlikely to change anytime soon, it seems a reasonable example.
Next time adding custom attributes to an element for easier automation comes up, consider whether they might make good aria attributes. It could add a lot of value to the effort.
If you have other ideas or examples of how testing and a11y improvements might enhance one another, please share in the comments!
