Thank you for the kind note!

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.