Accessibility at ZoomInfo

I led the design side of a company-wide accessibility effort at ZoomInfo. It started as a compliance requirement for a single enterprise customer and grew into a long-term program. I began as a solo contributor writing screen-level accessibility specs for the Sales app, then moved into leading a team of design champions, and eventually embedded accessibility into the design system so future work would start accessible by default.

One of ZoomInfo's enterprise customers told us 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 going in, so I had to build one while the work was already running. I studied with a Certified Professional in Web Accessibility (CPWA) contractor, worked through WCAG 2.1 criteria as I went, returning to specific guidelines and pattern examples as each new problem came up, and went through webinars and video walkthroughs in parallel. I later reviewed WCAG 2.2 to catch the gaps the new version introduced. The same CPWA consultant audited the work as it shipped, both to validate that my specs were accurate and to give the enterprise customer the official sign-off they needed.

The first phase was done solo. I went through the main screens of the Sales app one by one and broke each into accessibility specs that engineers could build against.

Component-level specs

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

Page-level concerns

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. A lot of this was new territory for the team, so I documented the intent next to each rule rather than just the rule itself.

Walking engineers through it

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

Obviously, one person couldn't cover the whole product, so 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, one designer per design domain, and trained each of them 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 spec to it, and walked me through their reasoning so I could correct and refine. I also curated a reference pack that included 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 extension (e.g., Landmark Navigation, Resolution Test) so champions could experience their designs the way assistive-tech users would.

Beyond that, I ran a webinar for the full design team covering both the UI side of accessibility (contrast, target size, typography, keyboard focus, zoom levels) and the UX side (keyboard interaction, use of color, semantic markup, and landmarks), so the rest of the team had a shared baseline too.

For day-to-day self-review, I put together a checklist that designers could run through before handoff.

The next step was making the design system itself accessible: a lot of the accessibility work was the same components repeating across screens. If the design system itself was accessible, the custom work would shrink to components that actually couldn't be solved at the library level, and everything else would arrive accessible out of the box.

A Figma format for component accessibility specs

I defined a Figma template for documenting each design system component. Every component got its own page with a consistent structure:

Name, role, value: what the component's accessible name is, what role it exposes, and what state it carries. Keyboard interaction: which keys focus, activate, dismiss, or navigate within the component. Plus focus state and any relevant ARIA attributes, with the reasoning written next to each one rather than just the rule (for example, `aria-hidden="true"` on a decorative icon prevents screen readers from doubling up when visible text already describes the element).

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

Pattern-level guidelines

Some accessibility work could not be constrained to a single component. Landmark structure, skip links, keyboard navigation across a full page: those are decisions at the layout level. So alongside component pages I added pattern pages covering, for example, how landmarks should be arranged on a page, how skip links should work, and what keyboard shortcuts should exist for jumping between landmarks.

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 moved through the org.

The design system now had accessibility built in, which meant standard components were accessible out of the box and designers only had to spec it for actual custom work, not every button and link 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 it easier to catch issues before they reached engineering. And engineers could fix accessibility in the component library once rather than patching the same component across every screen that used it.