Project
001
A11y Process
Taking 8 teams from 0 to 1 with accessibility.
The lack of process, individual ownership, and accessibility culture was causing poor quality of the experiences being delivered. These deficiencies were also proving to be expensive due to remediations.
Info
Role
Accessibility Specialist
Timeline
1 year
Tools
Research
Collaboration
Education
Overview
Problem
Build an accessibility program across 8 existing product teams. Fix low-hanging fruit first and then work towards maturity.
Outcome
All UX, Product and Engineering Leads completed Accessibility training. We also reduced the average time of an open accessibility bug ticket by more than half.
Note: This project has the client's name and other identifiers removed in accordance with an NDA.
All roles within these product teams required foundational awareness training.
In the large, cross-role teams that I work with it is common for teams to have a lack of foundational education. Utilizing workshops and shareable documentation we begin to build awareness and ownership. Failure in A11y education exhibits itself in these ways:
- Product has little understanding of how a11y fits into delivery and how their role should be involved.
- Engineering has inconsistent, or no, guidance on testing and “definition done” which creates uncertainty and poor quality work.
- UX has no process of a11y annotations and handoff to engineering which causes churn, tech debt, and poor user experience.
Priority One
Priorities & goals for Product Managers
- Plan for a11y review of designs and code during sprint and program increment planning
- Ensure engineering tickets have a clear definition of done regarding a11y
- Learn how to talk to stakeholders about prioritizing a11y tickets against competing priorities
Understanding where "a11y fits within delivery"
Part of a visual flow I put together to help teams understand where points of contact are within the formal a11y process.
Issue-tracking dashboards per team
Providing simple and clear reporting to teams and stakeholders is another key win. Being able to provide Product teams with relevant dashboards that display the state of a11y health at a glance. This is also a useful tool in talking to stakeholders about prioritization.
Team A11y dashboards in Jira
These were labeled with status, assignee, and — most importantly — priority. The priority levels and detailed info within each Jira a11y ticket allowed Product to be able to talk to stakeholders in an informed way about prioritization.
Priority Two
Provide guidance and clarity to Engineering
Most engineers I've worked with want to build and test for a11y before submitting a pull request but they are unsure exactly how to test and what criteria they should test against.
Testing guidance
Contributing testing guidance to the design system gave teams the ability to test with a keyboard and screen reader. This removes any excuse of "I didn't know how to test" when a pull request occurs. Doing this encourages responsibility and ownership.
Definition of done
I wrote a definition of done documentation to improve quality and consistency in delivery. This benefits the work by:
- Decreasing “low-hanging fruit” errors in development.
- Providing Product and Engineering and understanding of general testing criteria we use.
Provide guidance to engineers on how to fix
Don’t only report what’s wrong. Provide suggestions of how to remedy. Using code snippets, Codepen tests, and references I provide a path forward for Engineers.
Priority Three
Pairing up with and supporting UX
Creating A11y Design Annotations gets UX'ers to consider early how their decisions affect assistive tech users.
These annotations benefit teams in these ways:
- UX can now hand off designs with concrete guidelines, removing guesswork about interactions from engineers
- It provides testing criteria for UX, Product, and QA
- It is an educational opportunity for designers
This is a great opportunity to teach them about the use of headings, lists, links vs. buttons, etc. in code. After walking them through how to put together these annotations, I've found that designers get excited when they begin making these design-to-code connections and are usually off to running on their own in no time.
The Outcome
These steps resulted in the average time of an open accessibility bug ticket has been reduced by more than half as seen in this dashboard below.
And client stakeholders will get excited when they know you're delivering quality code and experiences.
