At Deque, we pride ourselves on delivering a complete set of tools and services to help our customers achieve success in web accessibility. The meaning of “complete” in this context is ever evolving, however. As we learn what our customers need in order to succeed, we react by incorporating their needs into our offerings.
Recently, in direct response to such a need, we learned how to augment the manner in which we identify and deliver accessibility issues to our customers’ development teams, and the results have been tangible improvements in ease of understanding and accuracy of remediation. In the content that follows, I will describe the need for this process improvement, and describe the benefits it offers to our customers.
Give your Developers Requirements
Riddle me this: What keeps a development team happy despite a recent influx of complicated and unfamiliar tasks? Clear requirements – it’s really that simple. Developers are willing to work hard, but first they require that product managers answer a couple deceptively difficult questions. Developers want to know:
- What are the stated goals for this task?
- How can I verify that I’ve achieved the stated goals?
Provide well-considered answers to these two questions, and marvel as your team turns your backlog into a pile of sawdust. This philosophy applies as much to the practice of accessibility remediation as anything else.
Why Accessibility Remediation is a Bad Word
For some developers, the phrase “accessibility remediation” signals a kind of sadistic guessing game. Aimed at the development floor, a sensitive ear will perceive all manner of frustrated utterances: “Is this even working as intended?”, “I guess this is good enough,” and so on. To understand how we arrived at this sad state of affairs, you need to understand how things have traditionally been done.
In the past, in order to kick off an enterprise-level remediation effort, it was customary for accessibility experts to swoop in from outside, perform a flurry of assessments and hand the results off to the in-house development team with a smile. “Here are your problems. Fix them and you’re all set.” A wonderful service, no doubt; but, since many developers have limited experience with accessibility, this hand-off often resulted in the exchange of strange looks, and crucial bits of what exactly “fixed” means got lost in translation.
At Deque, we’ve had success filling in this gap by making sure that we not only identify accessibility issues for our customers, but also translate these issues into formulae for solutions, which include implementation suggestions and validation instructions. Let’s look at an example of an accessibility issue, and see how it can be translated from accessibility jargon to the language of development.
Sam Checks his Mileage Plan
Sam, who uses a screen reader, wants to book a flight using a fictional airline called Excellent Airways. Before he books his flight, Sam is curious about the state of his mileage account, so he visits the airline’s website and logs into his account. The ‘Account’ page organizes information into sections, each section labeled by one of the following brief text headings: “Wallet,” “Mileage Plan” and “Discount Codes.” Screen readers, however, do not recognize these pieces of text as headings at all, causing Sam to have a rather confusing experience. Namely, Sam doesn not benefit from the hierarchical organization of information that is intended by these headings.
In this particular case, it’s all about semantics. On the ‘Account’ page, the so-called “headings” are just <div> elements with styles applied such that they resemble heading-like text. This approach is fine for sighted users who can distinguish between these pseudo-headings and the rest of the page’s normal text content, but it does nothing to help software, like screen readers, recognize the significance of these headings. By extension, Sam cannot recognize their meaning either.
Stating the Deficiency isn’t Enough
Continuing with our hypothetical example, the product owners at Excellent Airways are on top of things – they know they have some problems, so they engage a group of accessibility experts to assess their account pages. The experts happily identify the heading issue. Great! – especially since this type of accessibility issue is extraordinarily difficult, if not impossible, to identify using automated tools. Excellent Airways got its money’s worth.
Everything looks good so far. The issue has been raised, documented and heaped on the backlog. Weeks later, Amber, a front-end developer at Excellent Airways, pulls the heading issue, whose description reads:
Amber, already confused, begins work and immediately encounters problems.
Because Amber knows a bit about semantic markup, she assumes that she should at least change each piece of text to a heading tag (a good start, and further than some will get). In this case, though, the headings are generated by an code library, so she can’t just change the <div> tags to an <h2> on this one page without causing changes in numerous other places on the site.
Further, Amber wonders, “even if I did change the tag type, how would I know whether screen readers recognize these headings?” She needs more information.
Translating Problems into Solutions
Ready for an aphorism? The solution to the problem of problems without solutions is to add solutions to the problems. Re-read that last sentence; let it sink in.
An ideal ticket for accessibility remediation is comprised of many parts. Each piece has a purpose, and together they help the development team succeed. Let’s look at each component of the ideal accessibility remediation agile ticket.
Part 1: Overview
A very brief description of the overall issue – nothing earthshattering here. Nevertheless, every issue needs to stand out in a list view, and every new reader needs to be brought up to speed quickly.
Part 2: User Story
Here we see the use case for the remediation task stated as an agile user story. This helps:
- Clarify the business case for product owners
- Justify the work to developers
Personally, it still surprises me to see how much more motivated developers are to tackle accessibility remediation when they see a simple, well-articulated user story that highlights the tangible benefits of the proposed code change.
Part 3: How to Reproduce
Straightforward, but extremely helpful, this ensures that the developer working the issue can find it, and knows what precisely he or she is looking for. In conjunction with attached screenshots, this will relieve the need for many exasperated “What did you mean by ‘the link next to it’?” and “How did you get to this page?” emails.
Part 4: Remediation
A critical piece of the remediation issue, here is where Deque is able to leverage the development knowledge of our accessibility experts. This section includes detailed instructions for implementing the solution to the accessibility issue at hand, complete with code examples and alternative remediation options (where appropriate).
Noteably, the suggestions provided here are catered to the specificities of the customer’s codebase, development environment, and coding practices. Having such a close relationship with our customer’s development teams allows us to take into account factors such as the organization’s browser and assistive technology support matrix as well.
By providing detailed implementation suggestions, this section:
- Eliminates dangerous and frustrating guesswork
- Encourages consistent solutions to similar problems across the project
Part 5: Acceptance Criteria
Here we provide an explicit step-by-step guide to validation, including beginner-level instructions for cases in which validation requires the operation of special software, like screen readers, with which the developer might be only mildly familiar.
We’ve now come full circle. This section enables the developer to assert confidently that he or she has successfully fixed the issue. By mimicking the end-user’s experience, this section helps:
- Ensure accurate validation
- Promote user empathy
Conclusion
By not only identifying accessibility issues, but also providing solutions that are fit for consumption by today’s agile development teams, Deque is working to redeem the image of accessibility remediation as a positive and impactful exercise that actively brings the web to everyone. Remediation work need not be confusing and difficult, nor demand dice-rolls and stabs in the dark – and that’s good news, because that’s what today’s development teams demand.