Accessibility (AX) Testing in the DevOps Chain
Image Source: http://simplyaccessible.com/accessibility/
We often hear how important accessibility (AX) is for delivery, but we consistently see that it’s one of the first things cut as we get closer and closer to release (and we hope we’ll have the chance to properly address it later). As more companies embrace DevOps and Continuous models, how can we ensure that this extremely important aspect of development is no longer an afterthought? Ensuring accessibility takes understanding of what AX is, asking the right questions during design and implementation, knowing the tools that are available to help you, and making accessibility part of your acceptance criteria (and therefore, making it part of your Definition of Done).
What is Accessibility?
Web Accessibility allows people with diverse abilities to use the Web((https://www.w3.org/WAI/intro/accessibility.php)) — for example, people with cognitive issues (such as autism and ADHD) or physical (blindness, auditory, etc.). I recommend reading Anne Gibson’s post. She provides insight on a wide variety of health issues which many people might never consider — that could happen to any of us at any time — and the user personae.
Considering the range of issues people (your end users!) may be dealing with, it’s more important than ever to build apps that everyone can use — and it’s evident in standards that have been established to address this need (like Section 508((http://www.section508.gov/)) and Web Contact Accessibility Guidelines (WCAG)((http://www.w3.org/WAI/intro/wcag))).
AX and the Continuous Model
The problem I’ve seen is that accessibility is something we have to do, but is often not addressed early. It’s instead pushed out of the way until the end — and it can be very difficult to make features accessible after they’ve been built. Accessibility has been especially difficult in a Waterfall world. But how do you adapt what was previously an afterthought as more and more companies are moving towards a Continuous model? Accessibility needs to be up-front, starting with the design team. Here are some questions to be considered DURING design and development to help ensure you are considering AX needs early on. Although they may not necessarily ensure compliance with the standards, they will get you on that road: [table id=5 /]
There are many tools available to help ensure your apps are accessible:
- Web developer toolbars in browsers to disable CSS and check for logical reading orders (the non-CSS view is basically what will be read with a screenreader)
- Browser add-ons that reveal the underlying accessibility information (like WAVE for Firefox or Chrome)
- Desktop tools like Color Oracle to help simulate colorblindness
- Screenreaders that read the screen to you (people are mostly familiar with JAWS or VoiceOver for a desktop screenreader, but have you tried the accessibility options on your phone?)
Many of the tools are simple to use and don’t add a lot of overhead if some checks are done early in the development process (better to find issues early rather than later!) In addition to tools looking at what is already built, you may want to consider how you are writing your tests up-front. Perhaps you may want to look into extending your testing framework to add methods for keyboard navigation in integration tests, or ensure unit tests are checking for ARIA attributes. The important thing is to get your team on board to start thinking about accessibility, and provide them with the means to implement it.
Improve the Accessible Pipeline
It’s time to stop pushing AX to the end, and hoping for the best. As stories are designed, add accessibility to your acceptance criteria. Make sure that everything in your acceptance criteria is marked as complete (part of your Definition of Done). As with anything, the longer you put something off, the more difficult (and/or expensive) it is to implement later. In order to adapt to a Continuous world and keep up in the DevOps chain, AX needs to be considered early on, not later. Ashley Hunsberger is a Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She’s passionate about making an impact in education and loves coaching team members in product and client-focused quality practices. Most recently, she has focused on test strategy implementation and training, development process efficiencies, and preaching Test Driven Development to anyone that will listen. In her downtime, she loves to travel, read, quilt, hike, and spend time with her family.
- Appium Resources
- Best Practices
- Continuous Delivery
- Continuous Integration
- Continuous Testing
- Cross Browser Testing
- Guest Blog Posts
- Load Testing
- Mobile Development & Testing
- News & Product Updates
- Open Sauce
- Open Source
- Performance Testing
- Product Updates
- Quality Assurance
- Quality Engineering
- Sauce Product Info
- Security Testing
- Selenium Resources
- Software Development & Testing
- The Story of Sauce