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.
Author creates
Report, slides, form
Problem introduced here
Colleague reviews
Content and accuracy
Manager approves
Sign-off
Exported to PDF
Structure can be lost
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.
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.
Quarterly services report — illustrative example
Our achievements this quarter
The team delivered a full programme of community events, reaching more residents than in any previous quarter. Satisfaction scores rose across every service area.
Full event listings and booking details are available online. Click here
| Library visits | 12,400 |
| Events held | 38 |
| New members | 612 |
Exported to PDF via “Print to PDF”
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.
Link that says “click here”
Read out of context — as screen reader users often hear links — it says nothing about where it goes.
Table with no header row
Nothing tells assistive technology which cell labels which number, so the figures are read out without meaning.
Image with no alternative text
A screen reader announces only that an image exists — or reads out the file name.
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.
| Role | Documents | Presentations | Spreadsheets | Web content |
|---|---|---|---|---|
| Executive assistant | Required | Required | Recommended | Not assigned |
| Web content editor | Required | Recommended | Not assigned | Required |
| Data analyst | Recommended | Not assigned | Required | Not assigned |
| Communications staff | Required | Required | Not assigned | Recommended |
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.
- Step 1
Inventory
What documents exist?
- Step 2
Accessible templates
Start right by default
- Step 3
Staff training
Skills by role
- Step 4
Remediation priorities
Risk-based: public services first
- 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.