Have you ever received (or seen) an automated testing report for accessibility? It’s pretty overwhelming — usually a long list of “failures” printed out on several pages. They likely include one or all of the following:
Vague direction of where the problem persists
Redundancy with duplicate errors, exaggerating the breadth of the problem
Lack of clarity on whether the failure is a “technical” or “content management” issue
Absence of direction on remediation or expected result
The overwhelming reaction of not clearly understanding “the next steps” on remediation led me to architect our 225-point Accessibility Testing System. It’s a robust process that brings clarity to the present state of a site’s accessibility, shedding light on:
What the problem is
Where in the system it exists
Why it’s a problem
What needs to be done to resolve this accessibility issue
The benefit of this system is that it’s structured in a way that brings a shared understanding to the entire team — developers, UX, front end developers, QA leads, project managers, and stakeholders. This leaves no one out of the conversation (we are talking about accessibility here, aren’t we — and that means inclusion!).
Requirements & Acceptance Criteria
The two main areas for clarity are in the requirements and the Acceptance criteria. The requirements are written in plain language, outlining “what” needs to occur for compliance, supplemented by an Acceptance Criteria, a script that anyone can run through to validate accessibility. (I encourage you to take a read on “Acceptance Criteria” if it not familiar to you.)
The Acceptance Criteria is not only for validation, it is the conversation starter with the entire team, in which everyone comes to a shared understanding of what needs to happen. A developer can talk through potential solutions while a project manager evaluates scope. Rather than validating just “code,” we are assessing the entire experience in a manner that everyone understands. In crafting the Acceptance Criteria, I anticipate the user’s experience and interaction and work backwards.
Let’s take a simple search form as an example:
These are the assumptions:
The Search Box is a Text Field
The Search Icon activates behavior
Search Suggestions are available
Understanding these assumptions, we think through all of the assistive technology interactions:
Is the Text Field clear in its purpose? (e.g., does it have a label?)
Is the Interaction touchpoint clear? Is there some kind of announcement of this touchpoint?)
Is it clear how the user can interact with this icon? (are there audible instructions to activate it?)
Is the User aware of Search Suggestions? (Is there an audible indicator of suggestions?)
After form submit, is the user aware of successful submit? (do they receive audible confirmation?)
Is the text field easily accessible using a keyboard?
Is it easy for them to get out of the text field to form submit? e.g., there is no keyboard trap?
Is the user able to activate form submit with keystrokes?
So there’s quite a few things to check off in testing — and those can be tied to the requirements, so it’s helpful to have these touchpoints identified to ensure that the requirements cover them, while also serving as a reference for scope management. Ultimately an Acceptance Criteria may look like this:
Acceptance Criteria for the Sidebar Search Form:
As a user of assistive technology, I interact with and perform search from the sidebar.
The Text Field is preceded by a “Search” label to give context
A keyboard user uses keystrokes to navigate to, enter text, and exit the text field. (no keyboard trap)
A screenreader announces the purpose of the button, such as “button, search”
A screenreader is made aware of Suggested Search through audible alerts
The Suggested Search drop-down is accessible using keystrokes
The explicit Acceptance Criteria brings clarity to anyone on the team on the expected outcomes, thereby advancing education about accessibility expectations that they can add to their knowledge base.
Learn more about the importance of accessibility by watching my DrupalCon talk with David Spira. I’ll be presenting a similar talk this Friday at Twin Cities Drupal Camp!