AMA: Vox Product Accessibility Guidelines

over 7 years ago from , senior front-end engineer, vox media

Hi everyone!

We’re part of the team behind Vox Product’s Accessibility Guidelines. We’re excited to answer any and all questions you have about accessibility, Vox Media, our teams, and our favorite lunch spots, but before we get there, a little background on our foray into accessibility.

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.

Two months later, in July, we picked up the project again at our annual hack week, Vax. We sketched, wireframed, and built this checklist as a tool for teams to use. Guidelines are listed by role because everyone is responsible for accessibility on a team.

Ally Palanzi is a senior front end engineer at Vox Media based out of Washington, D.C. Currently, she works on the platform team working on a scalable system to create websites for our brands. Previously, she worked on design and development for both Vox and Polygon.

Sanette Tanaka is a product designer at Vox Media based out of New York City, and works with Ally on the platform team. Prior to that, she worked on Vox Media’s experimental, R&D team. Before she became a designer, she was a real-estate reporter at The Wall Street Journal.

Kelsey Scherer is a senior product designer at Vox Media based out of New York City. She works with the Storytelling Studio to help tell stories through clear and simple designs that best serve their audience. Previously at Vox Media, she worked on the relaunch of Eater and the relaunch of Racked.

Vox Media builds smart brands people love in categories they're passionate about. We are SB Nation, The Verge, Polygon, Eater, Curbed, Racked, Vox & Recode.

We’ll start answering questions at 10am EDT on August 31st.


  • Dirk HCM van BoxtelDirk HCM van Boxtel, over 7 years ago (edited over 7 years ago )

    Not a question, just a little note & a "thank you".

    I used to write/admin for SB Nation. They have a blog geared towards (and only accessible to) their writers that aims at teaching them how to both best use their CMS and write optimal copy for the web.

    While writing for them, I learned a metric ton of things I wouldn't have otherwise known. It was really insightful and I'm kind of sad I no longer have the time to write for them anymore and thus lost access to that great resource ;)

    But it's been a privilege and it's helped my career greatly.

    While this isn't a "thank you" to your team in person, you can accept it anyway, since I'm just happy to see a huge company be so dedicated to a craft that is dear to me; telling & spreading stories, online.

    10 points
  • Yitong ZhangYitong Zhang, over 7 years ago

    Hey y'all, thanks for doing this AMA — and for kicking ass in general at Vox!

    My question: how do you think about ad blockers? As someone who regularly uses one, I've seen sites like Wired and Forbes putting up ad block walls for me.

    I understand the business need, but walls seem like a pretty ham-fisted solution. Are you guys looking into other avenues?

    4 points
    • Tate TTate T, over 7 years ago

      Hi there, great question! I can help answer this one. Ad blockers are a result of people fighting back against bad practices -- there's room in all parts of the industry to improve standards, thoughtfulness, and security. We don't have ad block walls on our sites, and we don't have plans to in the future. We actually pioneered a new type of ad and placement in response to interstitials, one that I think is more thoughtful -- we call it Prelude.

      At Vox Media, we're always working on making better ad experiences -- we've got a Revenue team that's super passionate and amazing to work with. Shout out to everyone making Revenue better:

      Pam, Alisha, Brian, Megan, Heather, Drew, Winston, Casey, Messay, Steve, Guillermo, Scott, Matt, Ngan, Marvin, Nate, Josh, Kat, Constance, Alesha, Jack, Victor, Kevin, Corri, Ian, Jacqueline, Drew, Briar, Emily, Andrew.

      5 points
      • Yitong ZhangYitong Zhang, over 7 years ago

        Thanks for the quick reply, Tate! I actually just applied for a position on the revenue team haha. Fingers crossed that my name appears in that list one day!

        On the topic of Prelude: it's a good experience, but wouldn't it still get blocked by ad blockers? Is the hope that by improving the experience of ads, people will gradually uninstall their blockers?

        If so, is there consideration for making Prelude accessible to other sites as well?

        0 points
  • Leanne Macaspac, over 7 years ago

    How would you recommend integrating thinking about accessibility in terms of the design process? i.e., Do you begin with selecting appropriate fonts, followed by creating accessible brand colors? Or do you begin with wireframing?

    I suppose it could be a project-by-project basis (sometimes clients won't introduce branding until mid-wireframing, if not in the middle of high-fidelity mockups), but ideally what's the recommended process?

    2 points
    • kelsey schererkelsey scherer, over 7 years ago

      In terms of integrating accessibility best practices into the design process, it definitely depends on the type of work you are doing, and what process you are following. I’d recommend keeping general accessibility standards (or our handy checklist!) nearby as you design and keep the standards fresh in your mind. As you design different elements, you can refer to standards for each element. For example, if you are wireframing a form, refer to standards around form design, but if you are selecting brand colors, refer to contrast tests and set specific standards around how and when the colors are applied to different backgrounds.

      Accessibility should be thought about early and often, and throughout every part of a project. It’s not just something you check for at the very start or very end of a project.

      3 points
  • Brian EvansBrian Evans, over 7 years ago


    1. In regards to accessibility what would you advise is the best way to test for color contrast for WCAG conformance when your text is over an image on a responsive site?

    2. Do you have any great examples of accessible charting/graphs across your brand?

    3. Were any people with disabilities invited to collaborate on your standards? Do you guys do user testing with people with disabilities?

    Thank you for building this checklist. It's my new favorite accessibility resource online. Kudos! My only criticism is I'd add a QA or Editorial step to ensure the page's headings are descriptive. I see the developers have one for landmark roles when headings are actually used to navigate 65% of the time (According the the 5th Webaim Screen Reader Survey)

    2 points
    • ally palanzi, over 7 years ago

      Hi Brian!

      1. Text over an image is definitely tricky. I'm not sure of a formal way or tool for testing it, but what we've done is to try to pull out the dominant color in the image and compare that color with the text color to test contrast using a tool like Colour Contrast Analyser. We also will sometimes add a color overlay or drop shadow on the text to help with legibility. If the image is busy, especially on smaller screens, sometimes we even move the text off of the image.

      2. Not anything that I can think of right now, we included charting best practices in our guidelines so we hope to make them better in the future.

      3. One of the women who worked with us on these guidelines has a hearing disability, however, we haven't done any accessibility user testing yet.

      Thanks for the tip! We'll make a note to add that in.

      3 points
  • Jonathan ShariatJonathan Shariat, over 7 years ago
    1. How did you go about compiling the list? Were these things you learned over the years or things that were mostly new and you wanted to implement across all the properties?

    2. What would you say to a company that think implementing these will take too many resources?

    PS love the work, bookmarked!

    2 points
    • Sanette Tanaka, over 7 years ago

      Hi Jonathan! Great questions. To answer your first question, we started out by learning just what accessibility means to a modern media company. We brought in an expert, Jeremy Fields from Viget, who has written extensively on accessibility, and consulted books and online resources. We then went through various best practice lists and figured out what which guidelines made sense for our specific products and processes. The guidelines we included are a combination of ones that are not currently reflected on our properties, as well as ones that we already follow.

      To your second question, we are fortunate to work in a company that’s incredibly supportive of these efforts, but we understand that isn’t the case at many places. My best piece of advice is to start small. Our first formalized push in accessibility started with a group of six people and two days of work. We tried to come up with something of value immediately—which in our case, was role-specific guidelines on how to advance accessibility in folks’ every day projects. That helped us demonstrate the value to our leadership teams immediately. Later, we built on that foundation by presenting internally to different teams, building out the checklist tool, and so forth, but it all started with a small amount of resources.

      2 points
  • Mario VasquezMario Vasquez, over 7 years ago

    Using patterns that have already been tested is a great way to get started but it's always been a challenge to test accessibility. Real user testing, screen readers and browser plugins all have their strengths and weaknesses.

    What was the best combination that's worked for you to test accessibility and how has that evolved?

    1 point
    • Sanette Tanaka, over 7 years ago

      Great question. Testing is incredibly important, and we include a list of our favorite tools at the end of our checklist.

      Speaking for myself, I find it most helpful to test throughout my design process. So, for instance, I will test the contrast of color and type combinations in my Sketch files using a tool like Colour Contrast Analyser. Once the product is in production, I use the WAVE Chrome extension to check contrast and other accessibility best practices. I use Responsive Web Design Tester to test various screen sizes, and, if I have time, view it using Apple's built-in accessibility settings like grayscale.

      We include other testing plans for QA teams to run through in our checklist, but it's a good idea for others on a team to do the same. At minimum, we advise running a browser check like WAVE, navigating via tab navigation, and using a screen reader.

      0 points
    • ally palanzi, over 7 years ago

      As a front-end developer, for testing accessibility, I always start with the tota11y bookmarklet. It's really intuitive to use and gives suggestions for fixes right within the page. I typically use this tool several times when building something and fix accessibility issues as I go. I'll regularly check with designers if there are any contrast issues so we can fix those together. Once the project is a little further along, I always test navigating the page with keyboard and then if I have time, a screen reader.

      The most important thing to keep in mind is to test things as you build them so it's not too overwhelming at the end to make updates.

      0 points
  • Johnson VinoJohnson Vino, over 7 years ago

    I have one basic question:

    The guidelines are usually been in visual representation to make it more understandable than written documentation. Why you chose the documentation

    1 point
    • Sanette Tanaka, over 7 years ago

      Hi Johnson! I think you're asking about why we chose to create the checklist tool listing all of our guidelines, rather than release our text docs. We considered releasing the docs as they were, but we realized that the role-specific docs worked for our company, but might be too prescriptive for other teams. At the same time, we had been experimenting with one-off checklists for some of our own projects and found them to be really helpful. The checklist tool makes it possible for teams to create their own slimmed down docs containing only the guidelines relevant to the project they're working on.

      1 point
  • Brian A.Brian A., over 7 years ago (edited over 7 years ago )

    Thanks for doing this! I'm going to drop my question off early before I forget. :)

    You mentioned that you developed processes, guidelines, and tools that employees across the company could use. In my experience, that stuff—while great—only works if there's accountability. How do you plan on keeping people accountable and ensuring that these guidelines are used consistently and effectively going forward?

    1 point
    • ally palanzi, over 7 years ago

      This is a great question! And also something we're still figuring out. Before we launch products, they generally go through testing from our Quality Assurance team. It's a work in progress right now, but in the future we're going to ensure that along with standard browser and device testing we also test for accessibility.

      We strive to treat accessibility just as any other function or feature that needs to be checked off before something can be launched. We've been doing accessibility best practice presentations to spread knowledge across teams to show that everyone is accountable.

      1 point
  • nb birdsnb birds, over 7 years ago

    Hey, and thanks for sharing above mentioned resources. They are very valuable.

    My question is: do you have visual design(e.g. what feel and look graphics have to have) and user interface(e.g. how the CTA should look) guidelines? If yes, how they are distributed between Vox Media's different brands and how teams use them.

    Also would be very valuable if you could share those guidelines.

    0 points
    • kelsey schererkelsey scherer, over 7 years ago

      Hi Natalie!

      In terms of visual design vs user interface design, all of that is grouped under the Design heading, because at Vox Media we categorize product design, user experience design, and visual design all under one design group.

      We didn’t include every single accessibility guideline in our checklist, as they don’t all make sense in a checklist format. Viget’s interactive wcag was a big inspiration to us, and you can see guidelines there filtered by UX responsibilities, as well as design responsibilities.

      In terms of how they are distributed between Vox Media's different brands, our product team is a centralized team that works across all of our brands, so this is our internal documentation and our checklist website are shared resources that people from all teams can access.

      1 point
  • Kieran RheaumeKieran Rheaume, over 7 years ago

    I really like how you broke down the Accessibility Guide by role. Will surely help adoption :)

    My question: were there any accessibility edge cases that you deemed too abstract or rare to include in the guide?

    0 points
    • ally palanzi, over 7 years ago

      Thank you!

      Nothing that I can think of – we did a lot of research and tried to include all of the best practices. We try not to think of anything in regards to accessibility as an edge case because users may be "impaired" in certain contexts, situations, or periods in their lives, and still benefit from accessible products.

      2 points