By formally adopting web accessibility standards, you can provide access to people with visual impairments without involving them in the product development lifecycle, but does that mean the end product is usable? In this article, I’ll briefly discuss visual impairments, as well as the connection between web accessibility standards and usability principles. I’ll also share my key takeaways from a usability test I conducted with visually impaired and blind participants.
The term visual impairment refers to people who can see but have a decrease in visual acuity or visual field. Visual impairment affects the ability to perform daily activities, such as reading, walking, driving, and social activities — all of which become difficult (and sometimes even impossible). There is a range of visual impairments which vary from mild to severe vision loss in one or both eyes.
Here are a few examples:
Weaving is a method of textile production in which the longitudinal warp and transverse weft come together to make a fabric. As in weaving, the creation of a user experience for people with visual impairments is based on the interweaving of two components: accessibility and usability.
Web accessibility means that websites, web applications, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can: perceive, understand, navigate, and interact with and contribute to the web.
There is a range of disabilities that can impact how people access the web, including auditory, cognitive, neurological, physical, speech, and visual.
“The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect”.
— Tim Berners-Lee, inventor of the World Wide Web
In order to ensure the universality of the web and provide access to everyone, as Berners-Lee noted, there’s a wide range of web accessibility standards (which come with a myriad of acronyms).
Let’s focus on these three key components:
Compliance with web accessibility guidelines is technical and requires a high level of expertise. While you can use these guidelines to create a more accessible product, does that mean the product is also easy to use?
While I tested visually impaired and blind participants on a product that was accessible according to the guidelines, I encountered the following cases:
In other words, formal adoption of the web accessibility guidelines can certainly lead to compliance, but not necessarily usability. This is also recognized in W3C documentation where there is an explicit reference to the fact that usability must always be taken into account:
“Yet when designers, developers, and project managers approach accessibility as a checklist to meet these standards, the focus is only on the technical aspects of accessibility. As a result, the human interaction aspect is often lost, and accessibility is not achieved.”
I particularly like Bruce Lawson’s pictorial description in the introduction of the book Web Accessibility: Web Standards and Regulatory Compliance:
“I wouldn’t want you to think that making your sites accessible is just a matter of following a recipe; to make nourishing accessibility pudding, add one part CSS, one part valid code, a pinch of semantic markup, and a cupful of WCAG guidelines. It would be nice if I could guarantee that slavishly following such a recipe would make everything lovely… but the annoying fact is that people are people, and insist on having different needs and abilities.”
Compliance with accessibility standards is a necessary goal (and often required by law), but it can’t exist in a vacuum.
Usability is a measure of how much a specified user in a particular environment can use a user-interface to achieve a defined goal.
Usability is not an exact science that consists of formulas or black and white answers. Over the years, various usability models have been proposed for measuring the usability of software systems. One of the models was created by Jacob Nielsen, who proposed in his 1993 book Usability Engineering that usability is not a single, one-dimensional property of a user interface, but consists of five core attributes:
To ensure a product is usable, it’s essential that these five cornerstones are dominant in the design and development process.
A usability test is a structured interview where participants that match a target audience perform a series of tasks. While the participants are working, they verbally describe their reactions to interactions with the product. This allows the observers to understand not only what the participants are doing in the interface, but why they’re doing so.
When I conducted my first usability test with visually impaired and blind participants on a product that is in compliance with the accessibility standards, I wasn’t able to find too much information about conducting these types of sessions. So, I thought to share some highlights from the process. These are divided into three parts:
This is a starting point for a usability test. The test goal should be clear, specific, achievable, and relevant. The way we defined the goal is by collaborating with a multidisciplinary team: Designers, Product Managers, Developers, Content Writers, and QAs — each role brings a different perspective and expertise.
Since visually impaired and blind participants can take a longer time to complete tasks due to the way they navigate the site, we prioritized the tasks based on what’s most important to us, but this doesn’t mean that complex tasks need to be compromised.
Setting up our schedule for usability sessions required us to consider a range of issues, especially considering the complexity of our product and the physical limitations of the participants. This included:
We set one hour for each session and 45 minutes between sessions which was stressful and forced us to rush (it is better to take an hour between sessions).
The selection of participants whose background and abilities represent the target audience is a crucial component in the testing process. In our case, we were looking for visually impaired and blind candidates who have experience purchasing products online.
Sources for finding participants can vary, such as information and technology learning centers for people with visual impairments in hospitals, colleges, and universities.
In our case, my wife, an ophthalmologist by profession, referred me to the operator of the Information Center for the Visually Impaired and Blind at the hospital where she works. To my delight, I encountered someone who was happy to help and referred me to a group of relevant candidates.
In order to prepare the candidates, we discussed the following:
Overall the responsiveness was high, and most candidates expressed a desire to attend.
The candidates who confirmed their participation had different ways of interacting with the web. Some consume information by customizing settings for fonts, colors contrast, screen magnification, or listening to a screen reader, while some needed a combination of a few things.
Since most participants were not interested in bringing equipment with them (mainly due to difficulties carrying it or having a desktop computer), we had to take care of it ourselves. Once we found a staff member who understood how to configure the assistive technology, it didn’t take long to set up or adjust between sessions.
We set up various browsers and assistive technologies, including NVDA, JAWS, and ZoomText.
Additionally, the camera and microphone should be adjusted to the needs of visually impaired participants, who need to get closer to the screen and view it at different angles.
It’s necessary to check before starting that the lab is physically accessible as well. For example, that there are no stairs at the entrance, there’s an accessible toilet, access to public transportation, and a place for a guide dog to sit.
Like any other instance where you want to get informed consent, you can send the NDA online using an accessible PDF.
A week before the usability session, we conducted a dry run with a visually impaired participant in order to avoid unexpected difficulties. For example, we saw that the screen sharing tool we were using conflicted with one of the assistive technologies. Additionally, the dry run helped us get a better feeling for the schedule. For example, the introduction of the moderator was too long, so we weren’t able to check some of the planned tasks. Also, it helped us to refine the test plan in instances where certain tasks weren’t clear, more difficult than expected, or too easy. Just as importantly, the dry run allowed the moderators to train with a “real” participant, and mentally prepare themselves for this type of usability test.
The moderator is an important key to make this type of usability test go smoothly. Jared M. Spool once wrote:
“The best usability test moderators have a lot in common with an orchestra conductor. They keep the participant comfortable and stress-free. The moderator tries to make the participant forget they are in a foreign environment with a bunch of strangers who intensely watch everything that he/she does. They keep the information flowing to the design team, especially the tough news. And they do all this with organized flair and patience, ensuring every aspect of the user’s experience is explored.”
In a test with visually impaired and blind participants, the orchestra conductor should behave even more sensitively. For example, during sessions where a screen reader was used—which affects the concentration of the observers—it is important to ask participants to speak loud and clear, so we can understand their process and how they comprehend tasks.
We invited relevant people from different departments so they would be directly exposed to participants and have a better chance to absorb the key information. After all, getting a report on the results doesn’t provide the same benefits as seeing the participants’ experience firsthand.
During the test, it’s important to pay attention and listen to the participant–even though the screen reader is distracting.
After the sessions, we wrote a report with our insights from the test:
Some of the insights were related to bugs that we had to fix. For example, blind participants didn’t always find a particular button in the NVDA’s Elements List dialog, or sometimes they didn’t receive confirmation in the screen reader after clicking on the “Like” button.
Some of the insights were related to the content. For example, some blind participants didn’t notice they were filling out the wrong form or wanted to scan an entire page quickly, but the strings in the aria-labels were too long.
Some of the insights were related to visuals. For example, visually impaired participants who use magnifying software didn’t understand how to proceed when the next action appeared in a different area of the screen. Other times they didn’t notice the modal “close” icon — although its color was high contrast.
In the end, we found 65 issues that impact multiple departments in the company.
Additionally, our report included happy moments from the sessions. For example, some participants noted that using an icon next to a link helps them because they don’t have to read the text. Others liked the contrast of the placeholder text, and some mentioned that the image-zoom worked very well.
On July 26, 2020, the world marked the 30th anniversary of the signing of the American Disability Act (ADA). This opened doors that were closed too long for people with disabilities, such as participating in basic daily activities like traveling by bus, going to school, attending movies, visiting museums, and more.
All the events marking this historic signature were canceled or moved online due to the spread of the coronavirus.
One of the online events was the Virtual Crip Camp, featuring trailblazing speakers from the disability community. In the invitation to this event, there is a green bus with the slogan “Nothing About Us Without Us”:
“Nothing About Us Without Us” conveys the idea that a decision should be made with the direct participation of those most affected. The slogan came into use by activists with disabilities during the 1990s and is a connecting point between various disability rights movements around the world. The widespread use of the slogan (and in social networks using the hashtag #NothingAboutUsWithoutUs), reflects the desire of people with disabilities to take part in shaping the decisions that affect their personal lives.
The same DNA is common with the User-Centered Design approach, whose philosophy is that the product should fit the user—and not make the user adapt to the product. Under the User-Centered Design approach, there is a collaboration with users through a variety of techniques applied at different points in the product development lifecycle. Usability testing is one of those techniques.
The real magic of the usability test is not the reporting of data after the test, but the change in the perspective of team members who watch the participant in real-time and absorb what those participants say, think, do and, feel. As a result, they’ll develop empathy and better understand, reflect, and share the needs and motivations of another person.
In the case of participants with disabilities, this empathy is essential for many reasons — it harnesses the observers, creates motivation for change, and raises awareness about the experience for people with disabilities.
While automated tools that offer to make websites accessible can, at best, show us how well our site meets WCAG’s guidelines, they don’t clearly reflect how usable the website is for people with disabilities. In regard to a mechanistic approach to accessibility, my colleague Neil Osman, an accessibility engineer at Wix who is visually impaired, often uses the following expression:
“You can put lipstick on a pig, but it’s still a pig.”
Making a usable product is not just the ability to rely on a list of accessibility standards. In order to create solutions for people with disabilities, we need to be exposed to them firsthand.
Disclaimer: The information provided here does not, and is not intended to, constitute legal advice; instead, all information, content, and materials are for general informational purposes only. The information contained herein may not constitute the most up-to-date legal or other information.
Credits: Jeremy Hoover, Udi Gindi, Bat-El Sebbag, Nir Horesh, Neil Osman, Alon Fridman Waisbard, Shira Fogel and Zivan Krisher contributed to this article.