Skip to main content
My Blog
Insights & Stories

Explore my latest thoughts on design, development, branding, and the creative process.

Back to Blog
Accessibility10 min read
Making Accessibility Everyone's Job: How to Train a Cross-Functional Team

Accessibility doesn't scale when one person carries it. Here's how to build shared ownership across developers, content teams, designers, and managers.

E
Excelle Escalada
Digital Experience ArchitectDec 11, 2023

The one person who knows WCAG

Most organizations have one. The person everyone emails when an accessibility complaint comes in. The one who ran the audit, wrote the policy, probably named half the issues in the last external report. They're knowledgeable, overextended, and quietly dreading the next redesign.

This model doesn't work — not because that person isn't capable, but because no single person can review every content update, flag every design decision, and push back on every sprint without becoming a full-time bottleneck.

Accessibility embedded in the way a team works is fundamentally different from accessibility assigned to a person. One scales. The other doesn't.

Why role-specific training matters

The most common accessibility training approach is a single session covering the basics of WCAG for everyone at once. The result is usually surface-level awareness that doesn't change day-to-day behavior, because a developer building a custom dropdown and a content editor writing image captions need completely different knowledge to actually do their jobs more accessibly.

Role-specific training closes that gap. It focuses each person on the decisions they make regularly and gives them practical tools they can apply immediately.

What each role actually needs to know

Developers and front-end engineers

Developers benefit most from hands-on technical training. The goal is to make accessible patterns the default choice, not an extra step.

Focus areas:

  • Semantic HTML and when to use native elements vs. ARIA
  • Keyboard interaction patterns for custom components (menus, modals, accordions, date pickers)
  • Focus management: how to handle focus when content changes dynamically
  • How to test with a screen reader (VoiceOver on macOS, NVDA on Windows)
  • How to add automated accessibility linting to the existing development workflow
  • The most effective format is code-review-style sessions using the team's own codebase — not hypothetical examples. Reviewing a recent component together is worth more than three hours of slides.

    Content editors and copywriters

    Content teams shape a huge portion of what users actually experience. Link text, image descriptions, heading structure, plain language, and page titles are all content decisions with direct accessibility implications.

    Focus areas:

  • Writing meaningful link text (why "click here" fails and what to write instead)
  • Writing alt text for different types of images: informational, decorative, functional, and complex
  • Heading structure as navigation, not formatting
  • Plain language principles for cognitive accessibility
  • How to review their own content before publishing using free browser tools like WAVE
  • A 90-minute hands-on session using actual content from your site covers this well. Add a one-page reference guide they can keep at their desk and you'll see lasting behavior change.

    UX designers and visual designers

    Designers make decisions early in the process that either create accessibility debt or prevent it. Catching issues at the wireframe stage costs nothing. Catching them after development is complete costs real time.

    Focus areas:

  • Color contrast requirements and how to check during design (Figma plugins like A11y Annotation Kit or Color Contrast Checker)
  • What information should never be conveyed by color alone
  • Designing visible focus states (not hiding them with outline: none)
  • Spacing, touch target sizing, and reading order in flexible layouts
  • When and how to write annotation notes for interactive components
  • Designers respond well to critique-style workshops where they review previous design decisions and identify what they'd change. It builds pattern recognition faster than abstract instruction.

    Project managers and product owners

    PMs and product owners rarely need deep technical knowledge. What they need is enough understanding to plan for accessibility work appropriately and to recognize when it's being deprioritized.

    Focus areas:

  • Why accessibility issues cost more to fix after launch than before
  • How to include accessibility acceptance criteria in stories and tickets
  • How to read a basic accessibility report without relying on a technical translator
  • What "conformance" actually means and why "we passed the automated scan" isn't a complete answer
  • How to advocate for accessibility in roadmap discussions
  • A two-hour session framed around project risk and timeline is effective. Frame accessibility as a planning and quality issue, not an ethics lecture, and you'll get better uptake.

    Building a baseline awareness program

    Before role-specific training, a short organization-wide baseline creates a shared vocabulary. It doesn't need to be long.

    A baseline session covers:

  • Who accessibility affects and why it matters beyond legal compliance
  • The four WCAG principles: Perceivable, Operable, Understandable, Robust (POUR)
  • The difference between what automated tools catch and what requires human review
  • Where to go with questions and how to escalate an accessibility concern
  • Keep it under two hours. Record it for future onboarding. Pair it with a simple internal reference page so people have somewhere to look things up after the session ends.

    Sustaining accessibility knowledge over time

    One-time training builds awareness. Sustained practice builds fluency. The organizations that do this well treat accessibility as a recurring part of the team's work, not a training event.

    Practical ways to sustain it:

  • Include a brief accessibility check in design reviews and pull request templates
  • Add accessibility testing to the definition of done for any front-end work
  • Hold a quarterly 30-minute check-in where the team reviews one recent accessibility failure and discusses what could have caught it earlier
  • Rotate "accessibility buddy" duty in design critiques so different people practice giving accessibility feedback
  • Celebrate fixes publicly, not just initially in audits
  • The goal isn't perfection in every release. It's a team where more people catch more issues earlier, more often.

    When to bring in a specialist

    Shared ownership doesn't mean specialists aren't needed. It means the specialist's time is spent on higher-value work: complex audits, assistive technology testing, training facilitation, policy development, and external conformance reviews.

    A cross-functional team handles the day-to-day. A specialist handles the deep, complex, and strategic. Both are necessary. Neither can substitute for the other.


    If you want to build an accessibility training program for your team that actually sticks, get in touch and we can design something tailored to your roles, your content, and your timeline.

    Share this article

    More Articles