Process

Training Developers on Accessibility

By EZUD Published · Updated

Training Developers on Accessibility

Developers write the code that either creates or prevents accessibility barriers. Training them on accessibility principles, standards, and techniques is one of the highest-return investments an organization can make. A developer who understands semantic HTML, ARIA, keyboard interaction, and assistive technology testing produces accessible code by default rather than requiring remediation after the fact.

Core Curriculum

Semantic HTML

Most accessibility issues stem from misuse or neglect of HTML semantics. Developers should understand:

  • The difference between <button> and <div onclick>, and why the former is inherently keyboard-accessible with built-in focus, activation, and role.
  • Heading hierarchy (<h1> through <h6>) as a navigation mechanism for screen reader users.
  • Landmark elements (<nav>, <main>, <aside>, <footer>) and their role in page navigation.
  • Form elements: <label>, <fieldset>, <legend>, error messaging patterns.
  • Table elements: <th>, scope, <caption> for data tables; never using tables for layout.

ARIA (Accessible Rich Internet Applications)

ARIA extends HTML semantics for custom widgets. Developers should learn:

  • The first rule of ARIA: do not use ARIA if a native HTML element achieves the same result.
  • Roles, states, and properties: when and how to use them.
  • The W3C ARIA Authoring Practices Guide as the primary reference for widget patterns (tabs, menus, dialogs, comboboxes, tree views).
  • Live regions (aria-live, aria-atomic, aria-relevant) for announcing dynamic content updates.
  • Common ARIA mistakes: using aria-label to override visible text, applying roles without required children, using aria-hidden on focusable elements.

Keyboard Interaction

  • All interactive elements must be operable with keyboard: Tab, Shift+Tab, Enter, Space, Arrow keys, Escape.
  • Focus must be visible and managed: when content appears (modals, dropdowns), focus moves to it; when it disappears, focus returns to the trigger.
  • Focus traps are appropriate only for modals; all other content must allow free keyboard navigation.
  • Skip links allow keyboard users to bypass repetitive navigation.

Automated Testing

Developers should integrate accessibility testing into their workflow:

  • Linting: eslint-plugin-jsx-a11y (React), axe Linter (VS Code).
  • Unit tests: jest-axe or @testing-library assertions for accessible names, roles, and states.
  • Integration tests: cypress-axe, @axe-core/playwright for full-page accessibility scans.
  • Manual checks: keyboard navigation and quick screen reader verification for new interactive components.

See open-source accessibility tools and resources for a complete tool inventory.

Assistive Technology Familiarity

Developers do not need to become screen reader experts, but they should be able to:

  • Navigate a page with NVDA or VoiceOver using basic commands (headings, landmarks, links, forms).
  • Identify when a component is not announced correctly.
  • Test keyboard focus order and activation in their own code.

This practical exposure is more effective than disability simulation for building relevant skills.

Training Formats

Workshops (4-8 hours)

Intensive sessions combining instruction with hands-on exercises. Effective for initial training. Structure:

  1. Principles and standards overview (WCAG 2.2, Section 508).
  2. Semantic HTML exercises: fixing inaccessible page structure.
  3. ARIA exercises: building an accessible modal, tab panel, or combobox.
  4. Keyboard and screen reader testing lab: evaluating real product pages.

Code Review Pairing

Pair a developer with an accessibility specialist during code review. The specialist explains why specific code patterns create barriers and how to fix them. This one-on-one format is highly effective for skill transfer.

Self-Paced Courses

Deque University, Web Accessibility Initiative (WAI) tutorials, and Google’s Accessibility Fundamentals course provide structured online learning. Allocate dedicated time for completion; self-paced courses assigned as “extra” are rarely completed.

Communities of Practice

A regular accessibility discussion group where developers share challenges, solutions, and learnings. See accessibility champions program for how to structure this.

Measuring Training Effectiveness

Training without measurement risks becoming a checkbox exercise.

  • Pre/post assessments measuring knowledge of WCAG criteria, HTML semantics, and ARIA usage.
  • Code quality metrics: Track accessibility issues found in code review and automated scans before and after training.
  • Audit trends: Compare accessibility audit findings before and after training to see if the types and quantities of issues change.
  • Certification: Support developers in pursuing IAAP WAS (Web Accessibility Specialist) certification.

Report training metrics through accessibility dashboards.

Sustaining Knowledge

One-time training fades. Sustain knowledge through:

Key Takeaways

  • Developers are the primary implementers of accessibility. Training them has the highest return on investment.
  • Core curriculum: semantic HTML, ARIA, keyboard interaction, automated testing, and assistive technology basics.
  • Use multiple formats: workshops, code review pairing, self-paced courses, and communities of practice.
  • Measure effectiveness through assessments, code quality metrics, and audit trends.
  • Sustain knowledge through practice (definition of done), documentation, design systems, and champions programs.

Sources

More in Process

Inclusive Design Process Guide: Building Accessibility Into Every Stage Guide Continuous Accessibility Monitoring Accessibility in Design Reviews Nothing About Us Without Us: The Principle That Shapes Inclusive Design

View all Process articles →