I’ve been testing software professionally since 2001, when I was in my late 20s—when my eyesight was perfect. As I’ve gotten older, I’ve struggled with whether to make the font bigger on my web browser or phone, or to carry my reading glasses everywhere I go. I have to make this choice because some web sites were developed to account for this, and some weren’t.
As I get older, this problem is only going to get worse. There is a very very good chance I’m going to stop using your software if you get this wrong. Many others won’t even have a choice.
Sauce Labs believes software should enrich people’s lives, allow them to get their work (or play) done without headaches or access barriers. Accessibility is about equal access. This means that software should be equally usable by anyone and everyone, including people with disabilities.
If you’re not directly impacted or have a personal connection to disability, you may not understand how pervasive and impactful digital inaccessibility really is. The World Health Organization estimates that over 1 billion people have a disability, many of which may be completely invisible to you. My reading glasses are an assistive technology that enables me to use the web. Everyone eventually experiences these things in one form or another. This video by Deque Systems, Inc. perfectly illustrates the various reasons why this accessibility should be woven into your everyday approaches to software design.
Adjacent to the concern about your users’ experience is the threat of litigation, as illustrated by this article. Lawsuits have gained in both frequency and punitive liability over the past few years, and the time for excuses has run out.
Accessibility is now mainstream, and it’s a risk management issue that businesses have to face. Better education around accessibility, in design, development, and testing, can save you some costly headaches in both publicity and payouts.
Sauce Labs is proud to partner closely with Deque Systems, Inc. and their axe tool suite to introduce basic accessibility testing into our testing cloud. It’s as easy as adding a few lines of code to your existing tests, and it sheds light on areas of your software that might be difficult for some users to reach.
For more information about the business case for software accessibility, please visit this article from Deque.
Testing for Accessibility
In recent history, accessibility testing takes place near the end of a development cycle, just before release. Before that it was almost exclusively done in production—if at all. It’s typically done manually, by QA team members whose expertise is in functional software testing or test automation rather than accessibility. It’s expected to fit in with existing testing, to be done passively, alongside normal functional testing.
Deep accessibility testing requires just as much attention, focus, and energy as other kinds of functional testing, and it often requires making changes to phone or browser settings, to enlarge fonts, change zoom levels, rely on voice assistance, and the like. It usually can’t be done in parallel, because the testing relies on changes from outside the app itself.
In addition to this, it’s important to understand and cater to the different accessibility laws around the world, and sometimes even state-to-state, region-to-region. The W3C (the governing body around standards for the World Wide Web) has compiled a list of links to the various laws around the world, and it is being updated constantly as things change. In the European Union, for example, all Member States will enforce a certain defined degree of accessibility in all software by 28 June 2022, with a more rigorous set of standards to be implemented 3 years later.
Conversations with Sauce Labs users reveal that teams want to do more in this area, but seldom have time to study the different aspects of accessibility, and can’t take the time to do comprehensive testing to serve the needs of all users. People need help with this, which is where our partnership comes in.
Deque and Sauce Labs - Our Solution
The partnership between Deque and Sauce Labs enables Sauce customers to easily integrate accessibility testing into their quality processes, giving both testers and developers increased awareness and visibility into accessibility signals at every level of the software development process. With capabilities from Deque’s axe suite of tools integrated directly into the Sauce Labs Continuous Testing Cloud, Sauce Labs customers can now automate accessibility testing and gain greater visibility into accessibility issues as part of their end-to-end testing programs, while joint customers can seamlessly transition over to the Deque platform when a deeper dive into accessibility issues is needed.
Here are some tools that populate this tab. Instructions and examples for these can be found in the Sauce Labs documentation for Deque axe™ Integration.
Axe Selenium Integration for Java by Deque is a fully-featured accessibility library that allows for significant customizations for accessibility results.
Sa11y - the Selenium Accessibility Project includes basic libraries to obtain axe results with Selenium for Ruby and Python users. Developed as an open source project by the Developer Experience Engineering Team at Sauce Labs.
Selenium Axe Dotnet maintained by Troy Walsh is available for C# users as of the newly released v3.0.0
This solution is not meant to be a comprehensive solution for all accessibility concerns. It is meant to take some of the pressure off of your testing process, and give you enough information to know where the biggest, most obvious problems are. If there are 200-300 different things to worry about, this will prioritize the top issues and guide you toward how to fix them. This is an early warning indicator, intending to educate your team on accessibility concerns and to find low-hanging fruit that will make your user experiences better for everyone.
Though the solution covers browser-based Selenium testing at the moment, we expect to add mobile web and native app capabilities in the near future, giving you a deeper and broader understanding of your app’s accessibility issues.
If you aren’t concerned about growing your audience to include those with disabilities, you should definitely be concerned about shrinking your audience because you didn’t take action, and there’s a real chance you could wind up in court.
Let’s do better, and let’s do it together.