Forming alliances and establishing a guild

Making marginal gains on accessibility compliance is not a feasible task for one person alone. Since this was a large project consisting of multiple feature teams, it was important to build cross-practice alliances in order to make sustainable improvements.  

The guild’s formation

As a first step, I reached out to the project-wide Slack channel to determine interest in forming a group to identify and incorporate areas of improvement in the project’s accessibility practices.

A handful of project managers, engineers, delivery managers, and designers raised their virtual hands, so we created a project-specific Slack channel for our accessibility guild. The channel’s purpose was to asynchronously discuss goals, plan upcoming meetings, and provide a space for folks to ask questions.

Additionally, we held bi-weekly meetings to share updates on accessibility goals we were working on, demo improvements to the applications, and review newly submitted issues.

Tracking new and existing accessibility issues

One of the first topics the group tackled was how to track existing and new accessibility issues. We found that there were some issues floating in Jira while others existed in a spreadsheet that was created a couple years ago. Ultimately, we decided to create an accessibility inbox epic where issues could be tracked, prioritized, and assigned to engineers and designers in one location.

This method proved successful in that we were able to:

• Evaluate if previously submitted issues were still prevalent in the code base

• Providing a way for teams to submit new issues

• Prioritize issues against an upcoming deliverable deadline

• Slate issues within sprints to share the work we were accomplishing with the client

Brainstorming quarterly goals

There are many other ways to make marginal gains in a project’s accessibility compliance in addition to fixes in the code base. Projects at the company complete a quarterly accessibility score card that urges us to evaluate how accessibility is baked into the project from research to design to implementation. As a result, the scorecard provides insight into improvements a project can make to boost their accessibility incorporation.  

Planning goals in Miro

Once our group completed a quarterly accessibility scorecard, we would come together to identify goals we’re interested in tackling. This also provided pairing opportunities for cross-practice collaboration on goals. Some of our goals have included: identifying our Section 508 Program Manager, enrolling in the Trusted Tester program, and drafting an accessibility plan.

Tracking goals

Working in the open is an important value on a large multi-team project such as this one. Therefore, we created a quarterly goals tracker that’s publicly accessible to anyone on the team. This provides an overview of the committed goals for the quarter as well as each goal’s status, lead, and relevant documentation. Through this documentation we were able to stay on track and share our progress with the larger project team both asynchronously and in meetings.

Approaching accessibility issues as a designer

Many of the components used on the project are from the U.S. Web Design System (USWDS); as a result, the components undergo accessibility compliance testing by that team. This was a fantastic start since many issues that might arise with custom components weren’t prevalent.

However, there were still many items to resolve including missing page title announcements, insufficient color contrast ratios, and unannounced items in a custom dropdown component. The work was often collaborative between design and engineering to determine a solution and validate that the solution solves the problem during PR reviews.

Example issue: Insufficient color contrast

One of the more common accessibility issues that can pop up in user interfaces is insufficient color contrast per the Web Content Accessibility Guidelines’ (WCAG) ratio standards. In this case, text in various shipment cards did not meet the minimum WCAG AA standard.

Approaching the problem

To approach this issue, I created a Miro board documenting the components that were failing and commonalities between them. In one case, variations of a shipment card all contained the same failing text. However, different hex codes were being used in staging and Figma. I documented the discrepancies and suggested remediation options that aligned with our style guide.

Since I was suggesting a global change, it was important to share the work with the project’s entire design team for feedback. This also provided a way for other designers to get involved in the accessibility work as either an established skillset or learning opportunity.

Sharing with the project team

This work also provided an opportunity to share my process with the wider project team. During a project-wide meeting, I shared an overview of what WCAG’s color contrast ratio standards are, examples of passing and failing elements in our product, and the steps taken to resolve the identified issues. Sharing work with other practices is vital in spreading awareness about the importance of accessibility compliance and how we might resolve issues we come across in our development work.