Accessibility Implementation & Testing: Getting on the Same Page

rfp-robotRFP ROBOT: Website Request for Proposal Generator

The time has come for a new website (or website redesign), which means you need to write a website request for proposal or web RFP. A Google search produces a few examples, but they vary wildly and don’t seem to speak really to your goals for developing or redesigning a new website. You need to write a website RFP that will clearly articulate your needs and generate responses from the best website designers and developers out there. But how?

Have no fear, RFP Robot is here. He will walk you through a step-by-step process to help you work through the details of your project and create a PDF formatted website design RFP that will provide the information vendors need to write an accurate bid. RFP Robot will tell you what info you should include, point out pitfalls, and give examples.

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!

Drupal Developer

Posted on June 22, 2016 in Austin Drupal Development, Austin Web Designer, Drupal Developer, Drupal Development Austin, Expert Drupal Development, Web Design Services

Share the Story

Back to Top