Search posts, tags, users, and pages
Accessibility has become widely know and sort-for topic with a lot of developers and organizations advocating for the need to focus more on it towards building for the Next Billion Users. Lately, I've been trying to learn more about auditing accessibility and testing accessibility on the web.
What do you think about testing the accessibility of your project until it complies with all the accessibility standards and guidelines?
Concerning Accessibility Testing, check out this conversation between Ademola and I.
There are tools for automated accessibility testing and we should take advantage of them e.g linter plugins, CI/CD tooling. However, these should be the baseline. Manual testing is still necessary if we’re to be sure that our products are actually usable.
Automated testing is great for picking low hanging fruits like missing alt tags, alt tags with the words “image” or “picture” in them but they can’t tell if the context of the image was meaningfully conveyed.
Also in highly interactive UI widgets, automated testing could also be misleading. Treat them like Snapshot test – important but not final. Still TEST MANUALLY
I second Segun Ola. Automated testing can tell you that your code is technically capable of being accessible, but can't tell you if the funnel from the homepage to purchased product is too difficult to understand, or if the content is confusing. Even some technical issues are missed like color contrast over a gradient.
One of my favorite accessibility articles is "Building the Most Inaccessible Site Possible with Perfect Lighthouse Score" by Manuel Matuzovic. It perfectly demonstrates how automated testing can only get you so far. Unless you open up the webpage and try it for yourself, you will never know if your site is actually accessible.
Starting with tools like Lighthouse or the aXe Firefox and Chrome extensions are great ways to start testing and gaining knowledge about what issues your site is experiencing, and ways to fix them.
When getting started with screen reader testing, you'll need a list of keyboard shortcuts and gestures. Keeping these close at hand will help you learn and get used to navigating your app.
It'll take some time to ramp up, and you won't become accessible in a day. Be kind to yourself and your team, and keep at it. Every fix helps.
I think that using testing software, accessibility standards and guidelines is an excellent place to start! Setting accessibility criteria as part of our acceptance criteria is critical to ensuring our design intent makes it all the way to the finish line and has positive impact on how accessible our product is.
However, I caution us to not use the metrics those platforms provide as our end-all-be-all.
For example, a lot of folks will chase 100 percent on Lighthouse and be done. Manuel Matuzovic wrote an article on making a site with 100 score that was inaccessible.
Accessibility should be thought of something that we're constantly trying to improve; so setting an end threshold is dangerous.
On the flip side, I think that it means we can constantly make consistent, incremental change to improve our accessibility with each snippet and sprint.
Broadly I think that thinking of the next billion users, we should focus our attention on the people that will be the most harmed by automation, global climate crisis, and the digitisation of basic needs. A core part of accessibility is...access. As we approach 5G, we will start to build for 5G, but most of the world isn't on 5G. We have to be mindful of how going cashless and prioritising tap payment or using only digital means to vote is going to exclude people who systematically don't have bank accounts or must use cash for various reasons.
That, to me, is the guiding light of access that we must always prioritise: The billions of people who are least benefitted from the tech we build and most harmed by it.
Start by making sure you're using Semantic HTML. Automated tools can often flag errors here. Things get tricky when you have complex widgets e.g tabbed UIs, autocomplete combo boxes. For such widgets, follow the WCAG prescription for expected behaviour, ARIA-attributes and keyboard interaction. Following the guidelines should be enough to provide the proper signals to assistive technologies. These tools know how to interact with these standard widgets.
What should you test?