Accessibility at ZoomInfo

I led the design side of a company-wide accessibility effort at ZoomInfo. It started as a compliance requirement for an enterprise customer and grew into a long-term program. I began by writing screen-level accessibility specs for the Sales app, then moved into leading a team of design champions, and eventually led the work of building accessibility into the design system.

One of ZoomInfo's enterprise customers said they couldn't continue their subscription unless the product met WCAG 2.1 AA. I was asked to lead the design side. I didn't have a formal accessibility background, so I had to build one as I went. I studied with a Certified Professional in Web Accessibility (CPWA) contractor, worked through WCAG criteria, returning to specific guidelines and pattern examples as new challenges came up, and watched webinars and walkthroughs in parallel. I later reviewed WCAG 2.2 to catch the gaps the new version introduced. The CPWA consultant audited the work, both to validate my specs and to give the customer the official sign-off they needed.

Most of the first phase was solo work, with accessibility champions joining in once they were up to speed. I went through the main screens of the Sales app and wrote accessibility specs for engineers.

Component-level specs

For every interactive element (buttons, links, tabs, lists, menus, dialogs, etc.) I defined the role it needed, its accessible name, and how it should respond to keyboard. Additional ARIA attributes were added with reasoning. For example, a button with a prefix icon and visible label got aria-hidden="true" on the icon so screen readers won't announce the decorative part on top of the visible label and produce duplicated output.

Page-level specs

I also specified landmarks (main, banner, region, complementary, etc.), skip links, heading order, colors meeting WCAG contrast requirements, readable typography sizes, minimum clickable-area sizes, and how each screen should behave at higher zoom levels. This was new territory for most of the team, so I documented the intent of each rule as I went in an accessibility guidelines Figma file, which later grew to be part of the design system.

Engineering handoff

Some of the engineers I partnered with hadn't touched accessibility before, so the specs were paired with walkthroughs during handoff. Together with the CPWA consultant, I explained decisions such as when 'aria-label' is right and when 'aria-labelledby' is a better fit for the accessible name, why a native <button> beats a custom <div> wrapped in ARIA, how focus management works inside a modal, and so on.

Once the first wave of screens was done I shifted to scaling the work by training other designers. I assembled a team of accessibility champions covering different design domains, and trained each to be the accessibility expert for their area. The training was a mix of 1:1 mentoring, hands-on exercises, and shared reference material.

In the 1:1 sessions I went through critical WCAG criteria with each champion and worked through their specific questions. For exercises, each champion took a design they were actively working on, added accessibility specs to it, and walked me through their reasoning so I could correct and refine. I also curated a reference pack that included training materials, the WCAG 2.1 checklist, accessible design system references (e.g., IBM Carbon, GOV.UK, Angular CDK, Adele), and setup instructions for VoiceOver, NVDA, and various Chrome accessibility extensions (e.g., Landmark Navigation, Resolution Test) so champions could experience their designs the way assistive-tech users would.

I also ran a webinar for the whole design team covering both the UI side of accessibility (contrast, target size, typography, etc.) and the UX side (keyboard interaction, semantic markup, landmarks, etc.), so the rest of the team had a shared baseline. For self-review, I put together a checklist that designers could run through before handoff.

The same components and patterns kept showing up across screens, so the logical next step was making the design system accessible: if it was, the custom work would shrink to components; everything else would be accessible out of the box.

Figma for component accessibility specs

I created a Figma template for documenting design system components. Every component had its own page with a consistent structure: Name, role, value (the component's accessible name, role, and state), keyboard interaction (which keys focus, activate, dismiss, or navigate within the component), keyboard focus, and any relevant ARIA attributes.

I filled in the template for the first few components myself as a baseline, then allocated the rest between myself and the champions. I reviewed each one, and the CPWA consultant gave final approval before it went to engineering.

Pattern-level guidelines

Some accessibility work couldn’t be constrained to a single component. Skip links and landmarks sit at the layout level. Multi-component patterns like filters and the navbar are reusable and shouldn’t be redefined from scratch every time they're used in designs. So I documented them as pattern pages beside the component library.

The Sales app's critical screens met WCAG 2.1 AA on the deadline, and the enterprise customer stayed. Beyond that specific contract, the program changed how accessibility was handled across the design team.

The components we covered in the design system no longer needed accessibility spec in every new design. Every design domain had a trained champion, so accessibility reviews stopped bottlenecking through me or the CPWA consultant. The design team shared a common vocabulary (landmarks, roles, names, focus, keyboard) that made accessibility work faster and less error-prone. And engineers could fix accessibility in the component library once rather than patching the same component across every screen that used it.