Skip to main content
Stephen Hoang.Digital accessibility & governance

Stephen Hoang / Case study 02

Making Accessibility Everyone's Responsibility

How I developed a practical training program to help employees create accessible documents and digital content as part of their everyday work.

  • Program development
  • Training design
  • Change management
  • Accessibility governance
Audience
Content authors across the agency
Built
Courses, checklists, a training matrix, a roadmap
Adoption
26 of 43 completed by July 2026

Accessibility problems were being created before content reached the web team

Our website accessibility work was making measurable progress, but I could see a problem that technical remediation alone wouldn't solve.

Much of the content published on our website was created outside the web team. Employees regularly produced reports, presentations, meeting materials, forms, and other documents, which often passed through several people before reaching the website.

If accessibility problems were introduced at the beginning of that process, they often became someone else's problem to fix at the end. I wanted to change that—helping employees create accessible materials from the start rather than relying on remediation after publication.

Project evidence

Where accessibility problems entered—and where they were caught

A typical document's path to the website. Problems were introduced at the first stage but usually found at the last one, by the people with the least context. The training program aimed to move the fix to the start.

  1. Author creates

    Report, slides, form

    Problem introduced here

  2. Colleague reviews

    Content and accuracy

  3. Manager approves

    Sign-off

  4. Exported to PDF

    Structure can be lost

  5. Web team publishes

    Remediation at the end

    Problem was usually fixed here

The goal: give the author at stage 1 the skills to get it right first time.

The diagrams in this case study are reconstructed for illustration, due to confidentiality requirements. They are not actual screenshots, reports or client artifacts.

Training built around everyday tasks, not abstract WCAG

I developed a series of online accessibility courses for staff, beginning with common document and presentation tasks.

Instead of teaching WCAG as an abstract set of technical requirements, I focused on actions employees could apply immediately:

  • How do you create a proper heading?
  • What makes a table accessible?
  • How should you write descriptive links?
  • What happens to document structure when you export a PDF?

One exercise used two versions of the same document: an inaccessible example and a corrected version. Employees could compare the structure and see how seemingly small authoring decisions affected accessibility.

Project evidence

The exercise document, with its problems flagged

A simplified recreation of the inaccessible example learners started with. Each numbered marker flags an issue; the notes beside it explain what goes wrong for assistive technology. Learners then corrected the same document themselves — the words stayed identical, what changed was the structure assistive technology relies on.

  1. Heading made with bold, large text

    It looks like a heading, but a screen reader announces it as ordinary paragraph text. Users can't navigate by headings.

  2. Link that says “click here”

    Read out of context — as screen reader users often hear links — it says nothing about where it goes.

  3. Table with no header row

    Nothing tells assistive technology which cell labels which number, so the figures are read out without meaning.

  4. Image with no alternative text

    A screen reader announces only that an image exists — or reads out the file name.

  5. Structure lost on PDF export

    “Print to PDF” strips what little structure existed, so the published document arrives untagged.

Checklists that kept working after the course ended

I didn't want employees to have to remember an entire course every time they created a document.

I developed supporting materials, including a presentation accessibility checklist covering slide structure, reading order, alternative text, contrast, tables, links, and PDF export.

The approach was simple: teach the principles, demonstrate the process, and provide a reference employees could use independently.

Different roles got different training

Different departments produce different types of content. An executive assistant preparing board materials has different needs from someone managing website content or developing a spreadsheet.

I used a departmental training matrix to connect training requirements with staff responsibilities and track course development and rollout. This made the program more targeted, rather than assigning identical training to everyone. The curriculum expanded to cover additional digital authoring and publishing workflows.

Project evidence

How a training matrix maps roles to courses

Each row is a type of role; each column a course. Reading across a row shows exactly what one person needs, instead of everyone taking everything. Roles and courses here are representative, not the agency's actual matrix.

RoleDocumentsPresentationsSpreadsheetsWeb content
Executive assistantRequiredRequiredRecommendedNot assigned
Web content editorRequiredRecommendedNot assignedRequired
Data analystRecommendedNot assignedRequiredNot assigned
Communications staffRequiredRequiredNot assignedRecommended

26 of 43 assigned employees completed the first course by July 2026

Project evidence

Presentation accessibility course completion, July 2026

Each dot is one assigned employee. This shows real progress in an early-stage program—more than half complete—and how many people the next phase still needs to reach.

26 of 43assigned employees completed the presentation course

  • Completed (26)
  • Not yet completed (17)

The program also produced reusable resources—document examples, checklists, and course materials—that could support continuing staff development.

I collaborated with colleagues on incorporating foundational accessibility training into onboarding and recurring content-author workflows.

Training led to a roadmap for document governance

Employees needed both the skills to create accessible material and clear expectations about their responsibilities.

I developed a phased document accessibility roadmap, and drafted a risk-based approach to prioritizing documents that directly affected access to important public services.

Project evidence

The phased document accessibility roadmap

Five phases, in order. Each builds on the last: you can't prioritize remediation until you know what documents exist, and quality assurance only works once templates and training set a standard.

  1. Step 1

    Inventory

    What documents exist?

  2. Step 2

    Accessible templates

    Start right by default

  3. Step 3

    Staff training

    Skills by role

  4. Step 4

    Remediation priorities

    Risk-based: public services first

  5. Step 5

    Quality assurance

    Check before publishing

Together, these initiatives laid the groundwork for a more preventive approach to accessibility.

What I learned: change has to fit existing workflows

Creating a course is only one part of organizational change.

The more interesting challenge is making accessibility understandable and practical for people whose main responsibility is something else entirely. That requires relevant examples, manageable expectations, and resources that fit existing workflows.