Weaving Web Accessibility With Usability
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.
What Is Visual Impairment?
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:
Warp & Weft
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.
Warp — Accessibility
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.
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:
I particularly like Bruce Lawson’s pictorial description in the introduction of the book Web Accessibility: Web Standards and Regulatory Compliance:
Compliance with accessibility standards is a necessary goal (and often required by law), but it can’t exist in a vacuum.
Weft — Usability
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.
What I Learned From Conducting A Usability Test With Visually Impaired And Blind Participants
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:
1. Before The Session
Defining The Test Goal
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 A Schedule:
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.
Setting Up The Test Position
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.
Sending A Non-Disclosure Agreement (NDA)
Like any other instance where you want to get informed consent, you can send the NDA online using an accessible PDF.
Conducting A Dry Run Session
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.
2. During The Session
The moderator is an important key to make this type of usability test go smoothly. Jared M. Spool once wrote:
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.
3. After The Session
Writing A Report
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.
“Nothing About Us Without Us”
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:
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.
This content was originally published here.