Training Paths

Accessibility knowledge is role-specific. A developer and a content editor need different skills, different mental models, and different practical techniques. This page provides structured learning paths for each role — from a foundational understanding to practical skills to advanced practice.

All free resources are labelled. Paid resources are noted with estimated costs.

Beginner path (everyone)

Goal: Understand what web accessibility is, who benefits, and why it matters in a Canadian context. Time: 3–4 hours

Step 1: Understand disability and access (45 min)

  • Read Getting Started with Accessibility on this site — introduces POUR principles and disability types
  • Read Temporary and Situational Disabilities — establishes the “universal design” framing that connects accessibility to every user
  • Read the W3C WAI introduction: Introduction to Web Accessibility (w3.org/WAI/fundamentals/accessibility-intro) — authoritative 15-minute overview

Step 2: Understand Canadian law (30 min)

  • Read Accessible Canada Act on this site — who must comply at the federal level
  • Read AODA on this site (if Ontario-based) — compliance deadlines and requirements
  • Review Federal vs Provincial — clarify which laws apply to your organization

Step 3: Experience a screen reader (45 min)

The most effective way to build empathy for accessibility barriers is to use a screen reader. This is also the most direct education about why semantic HTML and alt text matter.

  1. Download NVDA for free from nvaccess.org (Windows) or enable VoiceOver (macOS: Cmd+F5)
  2. Open a webpage you are familiar with (your own organization’s website is ideal)
  3. Set your screen aside or close your eyes and navigate using only the keyboard
  4. Try to:
    • Find the main heading
    • Navigate to the contact page using the navigation
    • Complete a form
  5. Note what works easily and what is confusing or impossible

Step 4: Run an automated scan (30 min)

  1. Install WAVE (wave.webaim.org) or axe DevTools in your browser
  2. Run it on your organization’s website
  3. Review the errors and alerts — you do not need to fix them; just understand what categories of issues exist
  4. Read the descriptions of any errors found — these explain what the problem is and why it matters

Step 5: Read the Canadian context (30 min)

Designer path

Goal: Design interfaces that meet WCAG 2.1 AA criteria at the design stage, before code is written. Time: 8–12 hours total (including beginner path)

Prerequisites: Complete the beginner path first.

Phase 1: Visual design fundamentals (2–3 hours)

  1. Colour contrast (1 hour)

    • Read Design Principles — Colour Contrast on this site
    • Install Stark or Colour Contrast Analyser in your design tool
    • Check contrast in your current design system — note what passes and fails WCAG AA and AAA
    • Read WebAIM’s “Contrast and Color Accessibility” article (webaim.org/articles/contrast)

  2. Focus states (30 min)

  3. Touch targets and spacing (30 min)

    • Read Mobility Disabilities — target size section
    • Audit interactive elements in a current design: are all touch targets at least 44×44px?

  4. Motion and animation (30 min)

Phase 2: Information architecture and interaction design (2–3 hours)

  1. Cognitive accessibility (1 hour)

  2. Accessible component design (1 hour)

    • Read W3C WAI’s Designing for Web Accessibility tips: w3.org/WAI/tips/designing
    • Browse the ARIA Authoring Practices Guide patterns (w3.org/WAI/ARIA/apg) to understand keyboard expectations for components you design

  3. Accessibility annotations (1 hour)

    • Learn how to add accessibility annotations to design files
    • Read the Figma Accessibility Annotation Kit documentation (available in the Figma community)
    • Practice annotating one component with: reading order, heading level, ARIA role, alt text intent

Phase 3: Practical application (2–3 hours)

  1. Deque University: Accessibility for Designers (free course, ~2 hours)

    • dequeuniversity.com — search “Introduction to Accessibility and Inclusive Design”
    • Covers WCAG criteria relevant to designers with visual examples

  2. Conduct a design review of one existing page or component:

    • Check contrast (all text, interactive elements)
    • Verify focus states exist for all interactive components
    • Confirm no information conveyed by colour alone
    • Confirm touch targets are adequate
    • Confirm motion has a reduced-motion alternative

Ongoing practice

  • Run a contrast check before every design handoff
  • Include accessibility annotations as a standard deliverable
  • Review the WebAIM Million report (webaim.org/projects/million) annually — it tells you the most common failures
  • Stay current with A11y Weekly newsletter (a11yweekly.com)

Developer path

Goal: Implement accessible HTML, keyboard interactions, focus management, ARIA, and forms correctly. Time: 12–16 hours total (including beginner path)

Prerequisites: Complete the beginner path first.

Phase 1: Semantic HTML and CSS (3–4 hours)

  1. Semantic HTML (1 hour)

    • Read Development Practices — Semantic HTML on this site
    • Read MDN: “HTML: A good basis for accessibility” (developer.mozilla.org/accessibility)
    • Practice: open your current project, audit 3 pages — are headings semantic? Are buttons <button>? Are lists <ul>?

  2. WCAG for developers (1 hour)

    • Read WCAG Levels on this site
    • Read W3C WAI’s Tips for Developing (w3.org/WAI/tips/developing) — 10 quick tips with code examples

  3. Accessible CSS (1 hour)

Phase 2: Forms, tables, and ARIA (3–4 hours)

  1. Accessible forms (1.5 hours)

    • Read Development Practices — Forms on this site
    • Read W3C WAI: Forms Tutorial (w3.org/WAI/tutorials/forms) — comprehensive with code examples
    • Practice: audit a form in your project — are all labels associated? Are errors described? Is autocomplete set?

  2. Accessible tables (1 hour)

    • Read Development Practices — Tables on this site
    • Read W3C WAI: Tables Tutorial (w3.org/WAI/tutorials/tables)
    • Practice: find and fix any data tables missing <caption> and scope attributes

  3. ARIA fundamentals (1 hour)

    • Read Development Practices — ARIA on this site
    • Read MDN: “WAI-ARIA basics” (developer.mozilla.org)
    • Read the first rule of ARIA (w3.org/TR/using-aria/#firstrule)

Phase 3: Keyboard navigation and focus management (3–4 hours)

  1. Keyboard navigation (1 hour)

  2. Interactive widget patterns (2 hours)

    • Read Development Practices — Custom Interactive Components
    • Review the ARIA Authoring Practices Guide (w3.org/WAI/ARIA/apg) — focus on patterns you use: modals, dropdowns, tabs
    • Implement or audit focus management in your modal dialogs: does focus move in on open? Does Escape close? Does focus return on close?

  3. Dynamic content (1 hour)

Phase 4: Testing and tooling (2–3 hours)

  1. Automated testing setup (1 hour)

    • Install axe DevTools; run it on your project
    • Add axe-core to your test suite (jest-axe or axe-playwright)
    • Add eslint-plugin-jsx-a11y (React) or equivalent to your lint config

  2. Screen reader testing (1–2 hours)

Ongoing practice

  • Run axe on every PR before review
  • Do a keyboard walkthrough on every new interactive feature before merging
  • Review the ARIA APG when implementing any custom widget
  • Deque University: “Accessibility for Web Developers” (free, ~4 hours — dequeuniversity.com)

Content Author path

Goal: Write accessible content, publish accessible images and media, and use accessible document structure. Time: 5–7 hours total (including beginner path)

Prerequisites: Complete the beginner path first.

Phase 1: Writing and structure (2 hours)

  1. Plain language (1 hour)

    • Read Plain Language Writing on this site — the full page
    • Install the Hemingway Editor browser extension or use hemingwayapp.com
    • Paste 3 paragraphs from your recent work into Hemingway — note reading level and suggestions

  2. Headings and links (30 min)

  3. Lists and tables (30 min)

    • Review the tables section of Plain Language Writing
    • Check any tables you maintain: do they have captions? Are they used for data, not layout?

Phase 2: Images and media (2 hours)

  1. Alt text (1 hour)

    • Read Images and Media — Alt Text on this site
    • Practice writing alt text for 5 images from your organization’s website — compare your version to what is currently there
    • Read WebAIM’s “Alternative Text” guide (webaim.org/techniques/alttext)

  2. Captions and transcripts (1 hour)

    • Read Images and Media — Captions and Transcripts on this site
    • Review one video your organization has published — are captions accurate? Do they include speaker identification and non-speech audio?
    • Practice: correct the auto-generated captions on one video

Phase 3: Documents and PDFs (1 hour)

  1. Accessible PDFs (1 hour)
    • Read Plain Language Writing — Accessible PDFs on this site
    • Open your most-viewed PDF in Adobe Acrobat and run an accessibility check (Tools → Accessibility → Full Check)
    • Note failures and what would be needed to fix them

Ongoing practice

  • Use WAVE (wave.webaim.org) on pages you publish before they go live
  • Keep the Images and Media and Plain Language Writing pages bookmarked as quick reference
  • Subscribe to the A11y Project blog (a11yproject.com) for practical tips

Leadership path

Goal: Understand the business and legal case for accessibility, establish organizational policy, and manage accessibility as a program. Time: 3–5 hours total (including beginner path)

Prerequisites: Complete the beginner path first.

  1. Canadian legal requirements (1 hour)

  2. Business case (1 hour)

    • Read Temporary and Situational Disabilities — the “100% of people” argument
    • Review the ROI framing: market reach, support cost reduction, legal risk, SEO
    • Read WebAIM’s “The Business Case for Digital Accessibility” (webaim.org/articles/business-case)

Phase 2: Organizational strategy (1–2 hours)

  1. Roles and accountability (30 min)

    • Read Roles and Responsibilities on this site
    • Identify: who in your organization currently “owns” accessibility? Is that ownership formally defined?

  2. Procurement (1 hour)

    • Read Procurement on this site
    • Review one pending procurement — does the RFP include accessibility requirements?

  3. Program establishment (30 min)

    • Read “Developing Organizational Policies on Web Accessibility” at w3.org/WAI/planning/org-policies
    • Identify the three highest-priority actions for your organization

Ongoing practice

  • Commission an annual accessibility audit
  • Include accessibility in the organizational definition of quality
  • Track AODA/ACA compliance deadlines for your sector
  • Deque University: “Introduction to Disability and Accessibility” (free, ~1 hour) — leadership-level overview

Certification programs

IAAP Certified Professional in Accessibility Core Competencies (CPACC)

The International Association of Accessibility Professionals offers the CPACC — a foundational certification for accessibility practitioners in any role. Covers disability, law, and universal design theory.

  • Exam-based; study guide available
  • Relevant for any professional with significant accessibility responsibility
  • Recognized internationally

IAAP Web Accessibility Specialist (WAS)

Technical certification focused on WCAG implementation and testing. Appropriate for developers and QA professionals with significant accessibility responsibilities.

Deque University Professional Certificate

Non-exam-based; course-completion certificates for individual accessibility skills areas. Practical and role-specific.