Equinix
Building more accessible products
- Accessibility
- Content standards
- Design systems
- Company
- Equinix
- Project
- Accessibility Initiative
- My role
- Senior UX Writer
- Partners
- Research, Visual design, Interaction design, Brand, Marketing, Compliance, Engineering
Overview
Equinix’s products serve a diverse, global user base, but there were no standards in place to make sure they were accessible and inclusive. The goal was to bring them in line with WCAG.
As the Senior UX Writer, I owned the content side, creating clear, scalable accessibility guidelines and building them into new and existing workflows.
Problem
Without shared accessibility standards, the customer portal was harder to use for people with disabilities, especially those using screen readers and other assistive technologies. It also left Equinix exposed to legal and compliance risk.
Approach
Co-lead an accessibility workshop
Accessibility touches every discipline, so the whole team needed a shared foundation before aligning on goals.
I co-led a full-day workshop with our lead product designer for the design team and the broader Digital Services team. We learned WCAG’s principles together.
Auditing our products
We split off into groups to audit a few of our products. Each discipline flagged issues in their area of expertise.
Audit findings
- Content (me)
- Headers, descriptions, links, and labels not written for screen readers
- Visual design
- Color contrast and color dependence issues
- Interaction design
- Spacing and keyboard access issues
- Research
- Usability tests didn’t include screen readers or other assistive tools
Write and publish guidelines
I needed to give people who aren’t writers, like designers and engineers, a way to make sure content is accessible as they build.
I organized the guidance by category, pairing do’s and don’ts so they’re easy to scan, and explained the reasoning behind each rule so teams see how each choice affects users.
How it scales
I published the guidelines in the Equinix Content Style Guide and added content best practices directly to components in the Quix Design System, so teams find them while they build instead of having to look them up.
Present the initiative company-wide
For accessibility to stick, it needed visibility and accountability beyond the design team. So we presented the initiative to the whole company, explaining why accessibility matters, reporting what our audit found, and introducing our new guidelines and components. I covered the content accessibility portion.
Outcome
We didn’t have the engineering capacity to fix everything the audit uncovered. But with standardized design patterns, an accessible color palette, and the new content guidelines, everything we built from then on was more accessible, and screen readers and other assistive tools became a requirement in usability testing.
Content Accessibility Guidelines
Select a category to see its do’s and don’ts.
Do
- Write text that’s instructive, readable, and descriptive.
- Label things consistently.
- Underline links so they’re easy to identify.
- Write from the user’s perspective.
- Emphasize user benefits over product features.
Don’t
- Use generic labels like “click here” or “learn more,” because they lack context for people using assistive technologies.
- Put instructions in placeholder text, because users with low vision or cognitive impairments might miss the context entirely.
Do
- Add captions and text-based alternatives to help videos.
- Give non-decorative images text alternatives.
Do
- Identify the error and provide a solution.
Don’t
- Use technical messaging.
Do
- Write descriptive page titles and headers, and tag them properly (H1, H2, H3), so screen reader users can navigate to the right section.
- Give headers and labels an intentional information hierarchy.
- Make sure text and visual layout complement each other.
Don’t
- Write instructions with directional cues, because they may display inconsistently across devices and interfere with screen readers.
- Use all caps to show structure.
- Rely on color to show structure.
Do
- Keep the reading level simple enough for English-as-a-second-language readers.
- Provide a way to define words and abbreviations.
- Keep text readable and concise.
- Use active voice, because it’s more engaging and easier to understand.
Don’t
- Be repetitive, redundant, or ambiguous.
- Use jargon or technical terms.
- Use passive voice.
Do
- Make sure the language of pages and sections can be programmatically defined.
- Spell out acronyms and abbreviations.
- Provide a way to identify abbreviations, jargon, and how words are pronounced.
- Use inclusive language, free from prejudice, stereotypes, and discriminatory views.
Don’t
- Use abbreviations, jargon, slang, idioms, or hard-to-translate phrases.
Reflection
I came into this project knowing very little about accessibility, and WCAG felt overwhelming at first. Learning it alongside the team, then turning it into rules non-writers could actually use, made it manageable. 1 in 4 U.S. adults has a disability, so accessibility isn’t an edge case, and this initiative has taught me to write more inclusively.