Accessibility quality is related to usability quality, but focusses specifically on completing tasks easily, simply and intuitively as accessibility-needs users. For the practical purposes of software quality and testing, it’s beneficial to think of accessibility separately due to its importance over general usability and special standards and heuristics. It’s important the software is accessible to all without isolation or discrimination, so accessibility should always be an ethical, and not just business, goal.
Accessibility is prioritised by stakeholders whenever there are people who will be using the software.
A software program takes government data from a spreadsheet, processes it and then stores it into a database that can be accessed via an API. At the moment, only the person who developed the software uses the tool, there is no graphical user interface and they don’t have accessibility needs, so there is no scope for threats to accessibility quality. However it’s then decided that a graphical user interface will be developed so citizens can input their own data directly into the system. Now the software will be used by the general public, accessibility will become a top priority.
Threats to accessibility value may include:
- Use of red/green or blue/yellow only to differentiate between certain things
- Too small or difficult to read text for people with sight issues or dyslexia
- Poor contrast issues between different interactive elements
- Items flashing on screen too quickly that doesn’t give people time to read
- Missing alt-text so screen readers can’t be used
Some famous examples include:
- Dominoes Pizza was sued after a blind person tried and failed to use a screen reader with the application to order a pizza (Robles v. Domino’s Pizza, 2019).
Heuristics to test for accessibility quality may include:
There are currently no posts to show
Robles v. Domino’s Pizza. (2019) United States Court of Appeals for the Ninth Circuit. Available at: Link