clock menu more-arrow no yes mobile

Filed under:

Open sourcing our accessibility guidelines

Notebook with a11y stickers and glasses

In May, six Vox Media team members gathered in Washington, D.C., for two days to figure out how to approach accessibility on a company-wide scale. We have many advocates for accessibility throughout the company, but at the time of our gathering, we didn’t have a company-wide structure in place to implement standards across the board. Over the course of two days, we documented role-specific best practices and how each team member could implement them into their actual work. Later, we shared what we learned with the company.

Last week, we picked up the project again at our annual hack week, Vax. We sketched, wireframed, and built a website with our documentation that also serves as a tool to help teams consider accessibility at each stage of a project.


Our documentation is organized by role because everyone shares the responsibility of making our content accessible. Ensuring products are accessible should not only fall to the person building the product, or the QA team at the end. Accessibility should be considered at every stage, by every person.

Based on the documentation we put together for the Vox Media team, Sanette Tanaka began making one-off checklists for specific projects she was working on. While the docs we'd created were thorough, Sanette's experiences led us to the realization that others might also benefit from the ability to reference a slimmed down version of the documentation containing only the parts relevant to the project at hand.

Hack, hack, hack

Although Vax is referred to as our annual hack week, we only have two and a half days of actual design and build time. On Monday, the four of us sat down and began discussing goals so we could focus on getting a simple solution up and running by Wednesday afternoon. Our main goal was to create a simple tool that allowed users to create a custom checklist for accessibility guidelines based on their needs.

Messy notes showing a basic layout of checkboxes and titles, used to inform wireframes.
Notes taken while talking as a group, before making wireframes

After establishing our goal, we worked on some rough sketches, and moved quickly into wireframes. Wireframes and basic type pairings were all happening at the same time that the app was being built. The rest of the design happened in browser, with everyone on the team contributing to the entire package.

3 different type pairings, showing different typography options for header text and body text.
Quick type pairings on the wireframes

Open source

As a part of this project, we’ve made our Accessibility Guidelines open source. If you have ideas and would like to make this project better, contribute to the project on Github. If you have feedback, a feature request, or simply want to let us know about a bug, open an issue and we’ll check it out.

The team

You can find us on twitter @ssktanaka, @kelsa_, @mylifeasalllly, and @suchwinston.