Accessibility Checklist

Since May 2016, I have been part of a small grassroots effort at Vox Media to help advocate for accessibility in our products. In July, my team and I released an open-source checklist tool that helps teams anticipate and plan for accessibility in projects.

This is the story of how my team and I helped encourage adherence to accessibility standards across the company.

Challenge

Help designers, developers, product teams, and reporters across our 600-plus person company make their products and stories more accessible to a larger audience.

Solution

We created a checklist tool that lets teams cherry-pick accessibility guidelines that pertain to their specific projects, and generate customized project plans to keep them accountable.

Results

By helping teams consider accessibility early and often, our checklist makes a tangible difference in how teams approach their projects. Our tool has been featured in a number of sites including Nieman Journalism Lab and Designer News.

Role

I designed the checklist tool with Kelsey Scherer and worked with Ally Palanzi and Winston Hearn to develop it. In addition to the four of us, the original planning team also included Jessica Paoli and Mariah Minigan.

Process

Research and Planning

In May 2016, five of my Vox Media colleagues and I met in Washington, D.C., to figure out how to approach accessibility on a company-wide scale. As a media company, content is at our core. We believe everyone—regardless of ability, situation, or context—should be able to access it.

At the time of our gathering, we had many advocates for accessibility throughout the company, but no comprehensive system in place to ensure standards across the board.

After much brainstorming, whiteboarding, and a knowledge share with an industry expert, we ended the two-day gathering by documenting best practices by roles.

The Initial Concept

Two months later, we picked up the project again at Vox Product’s annual hack week. In the meantime, I had been experimenting with one-off checklists for some of my own projects and found them to be helpful. We realized that other teams might benefit from being able to create their own slimmed-down docs containing only the guidelines relevant to the project they were working on. That line of reasoning led us to this product idea: a checklist tool that would make it easy for teams to address accessibility from the start.

Sketching and Ideating

We then conducted quick user interviews with product managers present at the hack week to validate our idea. After defining our product, we started sketching.

Initial checklist tool sketches

Kelsey and I continued designing as Winston and Ally began building the app. Kelsey paired types on low-fidelity prototypes as I refined the content strategy and hierarchy of the app. Due to our short two-day timeline, we skipped robust wireframing and worked mostly in code.

Type explorations. We eventually chose to go with Lora and Open Sans. (Image credit: Kelsey Scherer)

Designing in Code

The rest of the design happened in code, with everyone on the team contributing to the entire package. We all opened, discussed, and closed functional and visual issues on GitHub. The issue below is a good example of how accessibility doesn’t just “happen”—it’s an ongoing effort.

This project is just one part of our ongoing efforts to encourage accessibility in our projects. We’ve writtenextensively about accessibility, presented both internally and externally, released our best practices presentation, and held an AMA on Designer News. Our checklist tool is open-source, and we’ve been thrilled to see others in the community adding to and enhancing the project.