Accessibility works best when everyone understands it
Accessibility isn't only a job for designers and developers. Product owners set the priority, and editors make daily decisions that keep a site accessible or quietly undo the work.
The workshop suits people on the tools and in leadership, whether you're starting a new project or taking stock of where you are.
What you get:
- A shared understanding. Common terms, key concepts, and clear roles across the team.
- Practical skills. Hands-on exercises in keyboard navigation, assistive technology, and screen readers.
- Confidence to keep content accessible. Editors leave knowing what to do on their next page.
What the workshop covers
We adapt the agenda to your team.
What accessibility means
We start with a definition of web accessibility and the terms and concepts you'll hear from auditors and in standards.
Who it affects
Accessibility affects people with physical and cognitive disability, and people in situational circumstances, such as using a phone in bright sunlight.
What the guidelines require
An overview of the WCAG principles and criteria, and who's responsible for each.
Where it fits in a project
How accessibility fits into the design, build, and content phases.
How to test
User testing and automated testing, with two exercises: a brief audit using keyboard navigation and assistive technology, and a screen reader demo.
Audits, strategy, and the case for doing better
How audits and strategy work, and why doing better pays off for your users and your organisation.
Frequently asked questions
Yes. We offer accessibility assessments as a standalone service or as part of a broader site assessment. Our experience covers WCAG 2.1 AA, keyboard accessibility testing, screen reader compatibility, and AS EN 301 549. Training for editors and site owners sits alongside that work.
Yes. An accessible component library can be undone by an editor who pastes formatted text from Word, skips heading levels, or relies on colour alone to convey meaning. Editors make these choices every day, not only at build time, so their habits affect compliance most after launch.
It goes beyond a WCAG checklist. It explains why accessibility matters to real users, how to structure content with headings, lists, alt text, and plain language, and how to use the CMS correctly rather than fight it. It should also be role-specific, because a stakeholder's responsibilities differ from an editor's. Pair this workshop with our editor training for hands-on Drupal skills.
At a minimum, when standards change, when your CMS or design system changes, and when new staff join the content team. Accessibility knowledge fades without reinforcement, and turnover in government communications teams is common, so a one-off session at project launch rarely holds up two years later.