As a software tester, you will know the importance of a good QA process, and the vital role you have in ensuring products are shipped error-free, and that your users enjoy a great experience.
When testing, it is easy to just focus on the functionality and features, highlighting and tracking bugs, and making sure everything just works. It can be easy to forget about the accessibility requirements a portion of your users may have, and whether considerations have been made. In this article, you will find some ways to help you and your team change your QA mindset and bake QA accessibility testing into the process, instead of accessibility being an afterthought. This way, you can prevent things slipping through the net that accidentally exclude people from enjoying your digital experiences.
User stories can help define accessibility requirements
In agile web development, user stories are used to describe what a user does, or needs to do, with a website or digital product. These “stories” are the basis for defining the functions that the system must provide, and they should succinctly capture the who, what, and why of the requirement. The features are then built from that story to help the user accomplish their goal.
A typical user story looks like this:
- As a [user role], I want [goal/desire] so that [benefit]
To bake accessibility considerations into the QA process, you may want to consider writing user stories with specific accessibility requirements in mind. For example:
- As a keyboard-only user, I want to be able to reach the main navigation links with the keyboard so that I can navigate the rest of the website.
- As a screen reader user, I want to know the labels for the form fields so that I can easily enter the correct information and submit the form.
- As a user who has difficulty reading due to vision impairment, I want to be able to enlarge the text on the screen so that I can read it easily.
There are many goal- or feature-specific questions that you should ask throughout the development cycle, such as “will my user be able to create a new item and assign it to another user by using the keyboard only”, or “will my users be able to read and understand the tutorial diagrams by using a screen reader?”.
But there are some more general questions that you and your team should ask when designing and testing any digital product. Here are a few examples:
- Does the application provide keyboard equivalents for all mouse operations?
- Do I know which screen readers my audience may use?
- Is my content structured in a way that makes sense for screen readers?
- Is documentation or instructions provided, and are these accessible?
- Are shortcut keys provided for menu items?
- Are tabs ordered logically to ensure smooth navigation?
- Does this application support multiple operating systems and browsers?
- Does my application or session timeout? Have I considered users who may need longer to accomplish their goals?
- Are labels written and tagged correctly?
- Have we considered the colors used in this application? Are they colorblind-friendly and can the user control them?
- Do my images include alt tags or descriptions?
- Am I using icons appropriately? If the icon has no text accompaniment, does the icon make sense on its own? Does it have an alt tag or description for screen readers?
- Does/should my application have audio alerts by default? Will this benefit or hinder my users? Can they adjust the volume controls, and if so, how?
- Does my application contain any moving or flashing images? Can my users control or adjust these?
The best way to test if your website or application is accessible is to involve people with disabilities or accessibility requirements, and actually see for yourself how they engage with your product. Not only will you get a first-hand look at whether your product meets their needs, you will have the opportunity to learn from people with this lived experience and get a new perspective.
Tools you can use when testing with accessibility in mind
Once you have developed a good understanding of accessibility requirements, and what to look out for and test during the QA process, things will become second nature to you. However you may often need to rely on tools and software to help you test more effectively. Here are some tools that can help:
- AATT (Automated Accessibility Testing Tool) – Provided by PayPal, it comes with an accessibility API and other web applications for HTML CodeSniffer.
- Free WCAG 2.0 Web Accessibility Checker – A free tool that reviews a single page and reports on any accessibility issues that it finds.
- The Accessibility Viewer (aViewer) – An inspection tool for Windows that displays the accessibility API information revealed to the operating system by web browsers, and consequently to any assistive technology like screen readers.
A huge list of accessibility evaluation tools can be found on The World Wide Web Consortium (W3C) website
QA testing is about making sure your users can have the best possible experience with the product you’re developing, and by considering users with additional needs and accessibility requirements as part of your processes, you will provide a better outcome for everybody.
This ‘epic’ user story encapsulates why we must consider accessibility during the testing phase: “As an individual with a disability, I simply want to be able to have an accessible experience on the system so I can fully take advantage of all features and functions.”