World Usability Day is intended to bring together communities of professional, industrial, educational, citizen, and government groups to ensure that essential services and products are easy to use and accessible by all. Unfortunately, recent experience has shown me that despite the best intentions of user experience designers and software developers, we are failing in our efforts to make software accessible for all.
Over ten years ago I wrote about The Intersection of Usability, Accessibility, and SEO with the premise that they are all really one and the same. Afterall, if you really think about it, they are all forms of usability; only the latter two serve special audiences—people with disabilities, and search engines, respectively. This is of course somewhat simplistic, although there are many differences between them, they are not completely unrelated.
Over the last twenty years at DesignHammer I have observed that many people, and most everyone in our industry were familiar with SEO, and to a lesser extent the concept of usability. I couldn’t say the same for accessibility though. Even ten years ago many designers and developers were unaware of designing and developing for accessibility, and while accessibility sessions are now prevalent at most industry conferences, we still seem to be failing in practice.
The reason I see the industry failing to serve people with disabilities is likely due to the perception that accessibility is removed from usability. Accessibility still seems to be regarded as a list of things to test for, in a vacuum per se, and not as a process that yields systems that are usable by people with disabilities.
To be honest, I didn’t really understand the difference between software that is usable by people with disabilities rather than just accessible for people with disabilities. As you would expect, a usable system is easy (or at least easier) to use, while an accessible system can be used, but often only with unnecessary frustration.
I have to credit John Samuel, Co-Founder/CEO of Ablr, an accessibility testing and inclusion consulting company, for explaining the difference to me. I met John a few years ago, and as a person with a visual disability, he explained to me that meeting accessibility compliance requirements doesn’t necessarily produce systems that people with disabilities can even use.
Over the last few months, John graciously participated on a panel with me at a couple of industry conferences in an attempt to explain this very difference. Ironically, John ran into software accessibility issues while attempting to interact with the virtual conference software on both occasions.
During the first session, it took John nearly twenty minutes to find the onscreen link for sharing his audio and video to join the panel because the link, while located front and center for sighted users, was difficult to find with his screen reader. Because the hyperlink was poorly named, it didn’t clearly indicate that it would activate the functionality he needed.
The second conference used the same virtual conference software as the previous conference, so this time John at least knew what link he was looking for, but it still took him five minutes to accomplish what I was able to accomplish in seconds. I was taken aback when John made an offhand remark about how he appreciated that the other panelists paused their discussion for a few minutes while waiting for the session to begin so he could hear his screen reader. I then made the shocking realization that the conference software did not have a volume control or mute button which meant John was unable to mute sounds from conference speakers while he attempted to find the link he needed using his screen reader.
Both of these examples underscore the issue with software that is technically accessible to a screen reader user but provides a poor user experience at the same time. If a screen reader user can find the correct link then yes, they can access it, but the user experience may have been more unpleasant than necessary.
How does this happen? Most likely as a result of accessibility testing that doesn’t consider principles of usable design specific to users with disabilities. The software was probably tested by a developer or QA tester who was intimately familiar with what the software did and how it worked. However, the testing probably was limited to performing simple tasks, such as “can you get to the link and follow it with a screen reader.” Clearly, accessibility testing alone can not substitute for usability testing.
How do we avoid this situation and create systems that are both usable and accessible? Our strategy is to use accessibility testers who are native screen reader users, and provide them with a set of scenarios to follow, rather than tell them which links to click. We know we have been successful if the tester can complete the task. If they can not complete the workflow sequence with ease, we acknowledge their feedback and try again. This process results in systems that are usable and accessible
On this World Usability Day, I hope readers will commit to doing better and strive to incorporate native assistive technology users into their usability and accessibility testing process. I also hope readers gain empathy for the struggles faced by people with disabilities, and channel their empathy into compassion. Compassion is empathy plus the motivation to make a difference.
Add new comment