Update on accessibility improvements we’re making to Chorus

As Lívia Labate recently wrote, “An accessible website is a website that anyone can use however they need to.” That’s an ideal we care deeply about here at Vox Media, but we haven’t been prioritizing it as much as we should have.

Over the last few months, we’ve been changing that. The product team’s been hard at work improving the accessibility of Chorus and every website powered by it. We’ve been working to ensure our websites are more usable for everyone, regardless of which browsers, devices, and assistive technologies they rely on. To reach our goal, we’ve been making improvements to our design system, and we’ve been creating new resources and training to inform our practices.

In this post, we’ll share what we’ve done so far, how your experience of browsing our websites might be improved, and—most importantly—we’ll talk about the work that’s still ahead of us.

Improvements to our design system

Chorus sites may look dramatically different, but each one is powered by a shared set of reusable interface components, or design patterns. Each masthead, color palette, and page layout is built on reusable bits of design and code. Since these components are used on every Chorus site, we partnered with the team at Prime Access Consulting (PAC) to guide our work. Through shared working sessions and detailed reviews, PAC has done much more than just audit each pattern in our design system, and to help us define the scope of our accessibility efforts. They’ve helped us broaden our definition of digital design, and shown us ways to talk and think more critically about how we work.

While the work is still very much in progress, we wanted to share some specific ways we’ve improved our design system—which, in turn, makes every one of our pages more usable.

Auditing our colors for sufficient contrast

Ryan Gantz, principal designer

Our accessibility audit surfaced a number of places where our colors don’t have sufficient contrast, making them difficult for audiences to read or perceive. Some of these colors can be fixed in a fairly straightforward way, for example, many of our story bylines and subtitles used a gray that’s much too light. We can darken those values globally, making them easier to read against a white background.

Similarly, some of our networks use a primary brand color that can leave links looking too pale, especially against light gray backgrounds. On The Verge, we changed that primary color to a slightly darker pink to remedy the issue.

Other fixes require more work. Polygon uses shades of pink that are regularly incorporated into gradient overlays, resulting in a contrast ratio that’s too low for white text set against them, for example. Some networks need further adjustments to their core brand colors, which means further exploration and coordination with their teams.

Making changes to a color palette that’s already in use isn’t always easy, but it’s our priority to make our design system and the foundations powering it accessible to everyone. Perhaps most importantly, our brand design team has made the same commitment for new color palettes. As more publishers come onto Chorus, we’re working closely to develop sites with good contrast ratios from the start.

Adding alternative text for social images

Nicole Zhu, full stack engineer

Images make up important parts of our stories, so in addition to supporting alternative text or “alt text” for images on our own sites and encouraging our editorial staff to write good alt text, we’ve added support for sending alt text for social images to Twitter and Facebook. When a link is shared on either of these social networks, we add optional metadata tags if the social image has alt text: “twitter:image:alt” for Twitter, and “og:image:alt” for Facebook.

A better structure for our pages and patterns

Ethan Marcotte, front-end architect

Our audiences use a whole host of technologies to browse the web. Some people visit our sites while using a mouse or trackpad, while others may use a keyboard, screen reader, switch, head wand, or another assistive technology to navigate our sites. Some may even use multiple technologies at once!

For users who navigate by tabbing or by sound, we’ve introduced a few ways to quickly access the content. The first is a skip link placed at the top of each page. The link is visually hidden by default, but can be accessed by pressing the “tab” key on your keyboard. If you use a screen reader, it should be the first item read aloud on each page. When you select the link, you’ll skip right over a site’s logo and navigation menus, and go right to the heart of the page you’re on.

In the following video, a “Skip to main content” link appears at the top of the Vox homepage when the “tab” key is pressed on the keyboard. After selecting a link, the browser jumps to the page content, skipping over the site’s masthead.

We’re in the process of making the structure of our pages more understandable to assistive technology and to the people who use it. We started introducing sections into our code, known as landmarks, allowing our users to quickly access different regions of content.

In the following video, the VoiceOver rotor menu appears over a story on The Verge. When the menu is active, I can navigate directly to the footer by selecting the “content information” landmark; after, I can use it to jump to the navigation at the top of the page.

Along with making our layouts more understandable, we’ve been introducing descriptive labels to our components, which can help assistive technology announce a component’s purpose when you navigate to it. In the following video, I’m using VoiceOver to navigate through the headings that appear at the top of Eater’s homepage. As I navigate, different key sections are read aloud: “Follow Eater online,” “search,” and “Eater main menu.”

We’ve also started improving how icons and logos are described. Before, a YouTube icon might be read aloud as “voxdotcom,” which wouldn’t give you a clear indication of what happens when you follow the link—doesn’t “Follow Vox.com on YouTube” sound much clearer? That’s why we’ve started adding better labels to these images, and we’d love your feedback as we continue this work.

Improving our teasers

Ambika Castle, front-end engineer

One big challenge we faced in making Chorus more accessible was in tackling our most ubiquitous and nested component: the teaser. Teasers were designed to entice you to read stories that are featured on homepages and landing pages. Teasers include an image, headline, byline, and tags—and this combination is one of our most complex components. It appears in several places throughout a site, appears differently in different contexts, and has different accessibility requirements depending on where it appears. In our codebase, it’s a single component, and a very complex one at that.

To make the teaser more accessible, we’ve gone down the difficult path of refactoring it. The changes we’re making won’t appear overnight, but when they’re complete, they’ll make every element on Chorus landing pages more accessible. To start, we’ve restructured the teaser so it can use the correct heading tag depending on where it appears. The first place we’re using this structure is in our two-up hero component, which promotes two stories.

If you visit our sites with a screen reader, we’ve added a few things that should make this component easier to use. First, a few non-visual headings better describe the purpose of the content you’re about to read. (And if you’re accustomed to browsing by heading, those extra headings make it easier to find and navigate the teasers.) We’ve also improved this component’s markup to be much more accessible.

For some of our users, the teaser component wasn’t very usable—in fact, it was broken. Because of the way the component was structured, the filename of the images were being read aloud as a string of gibberish. We’ve patched this bug, which should make teasers sound a lot better.

These are fairly modest changes, especially after such a large refactor. But by refactoring a component that’s heavily used across our sites, we’ve created a foundation we can build on. By ensuring the teaser component can be easily customized, we’re paving the way for more accessibility improvements in the future. Soon, our users will see similar usability improvements on all of our hero components and on the lists of stories below them.

Making our forms more usable

Nicole Zhu, full stack engineer

We’ve made some changes to make forms more accessible and easier to use. The first step was redesigning our newsletter signups, which appear on homepages, landing pages, and within the body of stories.

We added required field indicators both visually and in the HTML with the `required` attribute. We removed all use of HTML placeholder attributes, and added consistent form field labels. For people using assistive technology, we’ve improved the way newsletter signup forms are described. When you navigate to the start of the component, the specific newsletter title is announced in a more descriptive way, and the legal terms are read aloud before you can submit the form.

Resources and training

Of course, better pages and patterns are only half the work. To sustain accessibility practices over time, an organization needs to center the needs of the people affected by our design decisions. We knew we needed to talk about accessibility differently, so we sought out resources and training to help every member of our team do just that. We also wanted to hear directly from the people we’re designing for. Here are some of the ways we’ve started those conversations internally.

Encouraging continued learning

Lívia Labate, principal product manager

Having a shared long-term goal and commitment to making accessible websites was a great way to pique and renew everyone’s interest in doing this work thoughtfully.

We’ve had an accessibility channel in our prolific Slack for a long time but as we embarked on this journey, it became abuzz with questions, ideas, and new enthusiasm.

We knew that access to current materials was important to create a baseline understanding of people’s needs as well as technical solutions to satisfy them. Vox Media offers great financial support for professional development so the many book recommendations were devoured in addition to countless stories, videos, and research reports.

We challenged ourselves to increase our literacy of the Web Content Accessibility Guidelines as a reference for the scope of changes we needed to prioritize. We held a WCAG Thing I Learned challenge leading up to Global Accessibility Awareness Day, where teammates read a section of the guidelines every day for two weeks and shared a specific insight that helped them better understand the accessibility needs of our audiences and technical solutions to support them.

This was a great way to get us engrossed in accessibility practices and it generated even more enthusiasm, appetite, and questions about what it means to make accessible websites.

Learning does not happen on first exposure, however. Creating a strong foundation of understanding was as important to us as making necessary technical updates, so we invested in a new full-day event called Accessibility & Inclusion: A Day of Learning, which was open to the entire organization. Expert speakers who’ve been advocating for these topics for years joined us remotely to share their knowledge and insights. We held the event in a livestream, making it easy for our fully distributed team to participate. We also recorded (and captioned) the event for future team members to share on that same foundation.

These sessions helped cement our commitment and expand our framing of accessibility and inclusion including what it means to do this work with the people most affected by it, to the different circumstances of use that inform the scenarios we might test for, and the myriad design opportunities before us, among many others. These efforts have helped us establish a shared understanding of purpose, context, and ethics around this work—and set us on a very productive journey of learning that we’ll continue to pursue.

Training team members on screen reader basics

Ethan Marcotte, front-end architect

As our team began addressing accessibility issues, we knew we needed to get more familiar with different kinds of assistive technology. Screen readers felt like a good starting point: the product team uses macOS computers, which includes a copy of Apple’s VoiceOver screen reader. Now, VoiceOver is just one screen reader—NVDA for Windows is another very popular (and free!) screen reader—and of course, screen readers are just one form of assistive technology. But for us, VoiceOver felt like a natural, helpful starting point.

We ran two short sessions internally, helping our engineers and QA team learn some of the basics: how to start and stop the screen reader; how to navigate by headings, lists, or landmark regions; and how different kinds of images are read. Some of our engineers have started posting video or audio recordings of VoiceOver in their pull requests to demonstrate how their work improves or changes the experience.

Of course, as sighted engineers and designers, our experiences with screen readers will be dramatically different from those who rely on screen readers for access. But becoming more comfortable with VoiceOver has been an incredible first step for our team.

Documenting our accessibility standards

Nicole Fenton, communications manager

Along with training the product team, we developed new curriculum and documentation for our editorial networks to help them meet accessibility standards. We started by reviewing a wide sample of stories and videos to understand how teams were using features like subheadings, alt text, and closed captions. We reviewed resources from W3C, WebAim, the Accessibility Project, the National Center on Disability and Journalism, and more to pull together topic-based guidelines around text, images, videos, audio files and podcasts, tables, motion, and color contrast. We also audited recent support emails that touch on these topics to add more context to our guidelines.

We developed videos to demonstrate how screen readers work when reading stories, navigating by heading level, and announcing various combinations of alt text, captions, and image credits from Chorus. Throughout the process, we worked closely with accessibility experts at PAC to ensure the materials were accurate and thorough.

In May, we held a training workshop with managing editors, designers, and editorial stakeholders to test out the materials and to ask questions about decisions that affect people with disabilities. Since then, our networks have rolled out the training to their teams in smaller, individualized sessions and we’ve continued to add to our documentation as questions come up.

The work continues, as it always does

As a team, we think of this post as an update, not an announcement. Because our work’s not done—far from it. We’re continuing to refine and improve our internal resources; we’re still discussing how best to act on the design research we’re doing; and many of the components in our design system still need fixing, and even some of those mentioned here need further improvements to be truly usable.

But maybe an update’s okay. After all, designing and building for accessibility isn’t ever “finished.” Digital teams have to constantly, ceaselessly strive to improve their practices. As Lívia Labate notes, “trying, critiquing, using, rejecting, and adopting the right tools and processes is real work and an ongoing effort for the team.” In other words, we have to ensure we’re always delivering the most accessible work.

Successful accessibility work can’t be measured in sprints, launch dates, or deadlines. After all, our users help us shape the direction of our products, and we’ll always be adapting our practices to meet their needs. As we said above, we’ve identified many, many fixes we’re planning to make. But as we learn more about our users—and listen to our users—we’ll improve on our old approaches and design more accessible solutions that better meet their needs.

We’re in the process of making significant improvements to our platform, which will allow our team (and in time, our customers) to quickly and easily update the design of Chorus-powered websites. The future is bright, and it’s going to be a lot more accessible, too.