Let's start with the basics: what is User Interface Accessibility testing?
Accessibility testing is a test that allows enterprises to ensure that their product, platform, or application is accessible to anyone and everyone, regardless of a certain set of constraints.Unfortunately, even nowadays many companies skip this stage or do it as superficially as possible. They prefer not to spend "extra" time and resources, assuming that this test is more an altruistic impulse than profitable from the point of view of the business. Instead, making things accessible translates to better opportunities, as it means more people can use them.
First and foremost, design exists to serve all people, including those with various hearing, vision, movement, sight and cognitive disabilities. In addition, there are also temporary or situational limitations that are often overlooked.
For example, we can consider the permanent case of a one-armed person, the temporary case of someone’s arm in a cast, while the situational case is a subway ride where one hand is required to hold on to the handrail. If both hands are needed to use the application, we will use it much less often due to the intensive pace of life. This is a topic that businesses often bypass, thinking that they don't need it because their users don't have any limitations. The problem is that users with situational, temporary and permanent limitations will never be among the users of a product that is not accessible enough.
In practice, this audience has a significant ability to pay. For example, let’s take a look at the numbers in Italy: there are 3% of blind or visually impaired people, 8% who have hearing issues, 23% of elders, 2,5% who have dyslexia and 8,7% of non-native speakers who are also A11Y (Source: Istat).
A11Y stands for “accessibility.” It is a numeronym, with 11 representing the count of letters between the letter A and the letter Y.
Coincidentally, A11Y looks like it would read phonetically as ally, which has been the topic of controversy in some circles on social media. No less, many technologists see A11Y as a movement, and not just the simple act of making websites more accessible.
Let's take an example of a real test with a person who has a severe vision problem.
By testing your product on a screen reader with a person who is virtually unable to see, you can uncover a lot of details about your product that you didn't realize before. If you think an accessibility test is like a regular corridor test, only with a blind person, no, it's different altogether.
First of all, the meaning of "understandability" and "convenience" is completely different for people with screen readers. For a blind person "understandable" is when the elements in the voiceover are in the order logical to the ear, not as drawn, and there are no scraps of technical words/pieces of code. "Convenient" is when everything important is voiced, and everything that could be hidden or removed is absent.
Secondly, if you just turn on a screen reader and walk through the interface with your eyes closed, it's not the same. Here is an example of the feedback you can get when testing with a real person (names are arbitrary):
- The interface didn't say it was loading. Since the animated loader was not identified by the screen reader, the screen was blank for Marco. You have to check and sign the start and end of loading, especially if you have custom loaders.
- You can open content in frames and modal windows, the main thing is to specify the hierarchy correctly and not to announce what is under the modal window when it is open.
- Illustrations are better to remove if they do not carry a semantic load and it is fashionable to click on them and/or are important for understanding the content.
- When the 'button' component is used, screen readers identify this element typically by vocalizing "click" and then stating the button's name. The primary method for assigning an accessible name is using a text element within the element itself. That's why it's essential to ensure that all the titles of the links, buttons and controls are given the appropriate names.
From an entertaining observation: blind people are just as likely as sighted people not to finish large blocks of text. Just as we read "diagonally", they listen only to the beginning and, if they are not interested, skip to the next block.
There are actually a lot of accessibility tools and everyone chooses a tool depending on the purpose of testing and the need. I will mention some of them:
The accessibility test described above is just one single practical example. In real life, people with disabilities (only temporary) are a huge audience in England alone, for example, with a total spending power of £274 billion a year with 16 million new potential users. So, we can only imagine how the sphere of UX/UI itself could change if we start taking the accessibility testing phase more seriously and widely.
From a practical point of view, the interface which is convenient and understandable for a user with limitations becomes more understandable for an average user as well, that's a fact.
This is a question of product quality. The practice of accessibility testing should be a mandatory phase, because it is of interest to the business, the user and the designer among others, because it is important to us that our interface is up to par.