So what is “accessibility”?
One definition of Accessibility says that it consists of the practice of making a product usable by everyone, with or without disabilities.
This concept is often confused with usability, and the main difference is that accessibility is focused more on people with disabilities, where usability focuses on all the other aspects.
An “accessible” product or a product that was designed, developed, and tested with accessibility in mind, will have more users than a product that is not accessible.
The obvious fact is that the product's user population also includes disabled people.
Just as an example, recent studies show that (unfortunately) there are millions of people with some form of disability that have a long-term illness, impairment, or disability.
Although the figures shown in those statistics, there are companies that still don't design their products considering the accessibility practices.
Nowadays we have mostly every service that is accessible online, and we rely on the internet to perform most of our tasks and in a great number of cases our jobs too.
So, this fact adds more pressure on businesses to develop their applications in an accessible way.
In this way the companies now have a responsibility to provide all that they develop in a way that can be accessed by everyone.
As the customers now have different means of communication that are used to consume information and services, the websites and the mobile applications need to be designed and developed considering the “A11y”.
You would probably have heard about the Domino's Accessibility case where a blind man sued Domino's because he couldn't order his pizza from their website and mobile app, even with using a screen reader.
At the moment the law and regulation around web accessibility is still a blurred area.
If you have a website that's low in accessibility, this doesn't automatically mean that you will be sued.
However, accessibility issues can cost loss of users, which in turn, loss of money to the business, which is why it's a serious issue that needs to be addressed.
Web Content Accessibility Guidelines 2.0/2.1
The W3C has come up with the Web Content Accessibility Guidelines (WCAG), which provides a list of guidelines and recommendations on how to make your website more accessible.
Version 2.0, (December 2008), contains a set of rules which were grouped under four categories: Perceivable, Operable, Understandable and Robust; POUR as it’s known acronym.
Then version 2.1 (June 2018) was published to cover mobile accessibility, people with low vision and cognitive and learning abilities.
What this implies is:
Perceivable that means that the information should be presented to your users in different means.
Some of your users might have some difficulties with one of their senses, which means that they have to be reliant on using assistive technology, such as screen readers to access your website.
Operable refers to the principle that your users must be able to operate your website by using different means (using only a keyboard instead of a mouse).
Understandable is about making sure that your users can understand the information presented to them when using your website (Clear instructions and clear error messages is a mistake takes place).
Robust refers to making sure that your website must be used by your users when they use third-party assistive technologies, even if the technology advances.
Version 2.1 was introduced due to the rise of mobile devices and tablets, and to also cover a wider array of disabilities, such as people with low vision or cognitive and learning disabilities.
With this version, you need to make sure that your website is accessible in both portrait or landscape mode.
If you have animations on your website, you need to make sure that you have the option to turn them off. Also the ability to zoom text easily, so people with low vision can read it without issues.
WCAG 2.1 Conformance Levels
Each of the guidelines (2.0/2.1) have a success criteria.
This is defined through the three conformance levels that businesses or companies should achieve.
Level A is the most basic conformance, you must achieve 25 criteria from the accessibility guidelines.
Level AA is mid range, apart from achieving 25 criteria from level A, you also need to achieve 13 new criteria on this level.
Level AAA, which is the highest conformance level, meaning that you need to achieve the previous two levels, as well as another 23 criteria on top.
It's not mandatory to achieve level AAA as this is more targeted to specialist websites.
The recommended level is level AA, and this is the level that most teams are aiming to meet.
Why is A11Y testing important?
First of all, doing A11Y testing is just the right thing to do.
Designers and developers need to be empathetic to users with disabilities and put themselves in their shoes.
As more and more information can now be accessed online, they need to start thinking about how all users will use the products.
It’s important to include everyone and this not only benefits individuals, but the society as a whole.
Better accessibility means better user experience.
For example, if you are testing a website that has great design, animations and all these exciting features but poor accessibility, this leads to bad user experience.
So your job as a tester is to help your team find different accessibility issues so you can help deliver a high quality product.
It’s common to think about a11y testing as a task to do only after a product has been deployed to production but it’s real that if something works functionally does not necessarily mean accessible so we need to make sure that the user experience is considered.
Better accessibility also means that you widen your reach to other audiences.
How can automated accessibility tests help us?
With the amount of different accessibility checks that we need to do, it makes sense to automate some of them and get it added as part of our automated suite.
By automating some of the accessibility tests, we can catch basic accessibility issues earlier on and this allows us to collaborate more with our design and development team.
This can also serve as a living documentation to your team.
By having the automated tests in place, you have covered the issues your team have fixed in the past, so those will not be deployed to production again.
Although automated accessibility tests will only catch a subset of the accessibility issues out there, it’s still beneficial to have them because it will help us speed up our testing process and they are not expensive to run.
Lastly, having automated accessibility tests provides a fast feedback loop to your design and development team, especially if the tests are running as part of your continuous integration pipeline.
The importance of doing accessibility testing with actual users
With that said, nothing beats actual accessibility testing with real users.
You can have all the automated tests you need and even do some of the testing yourself, but there’s still a lot of benefit to gain if you invite real users with disabilities to test your website.
The reason being is that they probably use different third party assistive technologies and this way, you have that first hand understanding on how they use your product on a day-to-day basis.
Get them involved when your team is designing and developing a new feature.
They can provide valuable inputs on how to make your feature accessible.
With that said, if you are going to get user involvement, make sure that you involve different people with disabilities to get better results.
One person can use different assistive technology than others, so it’s best to not rely on one person’s input.
Some tips for accessibility testing
1.- Decide with your team what WCAG level you want to achieve.
2.- Get involved with your UX team and collaborate with them.
3.- Ask real users to get into the A11y testing
4.- Start testing on a basic page and just play around with it.
5.- Use your keyboard more and try not to use your mouse.
6.- Play around with screen readers.
7.- Turn off your speakers and test if there is a way to turn subtitles or captions on.
8.- Use an a11y testing checklist so you have an idea on what to track and what to suggest to your teams to fix.
9.- Do exploratory testing and timebox your sessions. Set the goal that you want to achieve.
10.- Don’t forget to decide on what other tools can help you.
Conclusion
As it is clear, a11y testing is another testing branch that has no minor weight. Implementing this practice you can leverage up the quality of your delivered products making them available for a wider number of users so your market reach and penetration is immediately increased.
The most important thing from my perspective is that, as it was said, implementing a11y testing practices is the right thing to do, so that’s another factor that helps us to be in the correct way to deliver quality products.
And one last thing. Always remember what we said in previous articles: “We have to aim to produce quality, more than to control it”
