Digital accessibility training for teams
Most accessibility problems repeat because nobody is sure whose job they are. Design assumes development will handle it, development assumes QA will catch it, QA assumes it was specified. Our training fixes that: each role learns the part they own, on your real product, mapped to the WCAG and Section 508 criteria your work is measured against.
Our accessibility training courses
Six courses, each built for a specific audience. Most teams start with one and add others as accessibility moves through the organisation.
Training for developers
Semantic structure, keyboard behaviour, focus management, ARIA, form handling, and interactive components, tied to the WCAG success criteria each decision maps to.
Training for designers
Contrast, focus visibility, component states, error messaging, and navigation logic, so accessibility debt never reaches the backlog.
Training for QA and testing teams
Keyboard-only testing, focus validation, common failure patterns, and how to write a finding against a criterion without over-reporting.
Training for product and content teams
Headings and reading order, link and button text, alternative text, captions, and accessible documents.
Hands-on workshop on your product
A working session where the team tests your real pages, components, and flows with us, instead of practising on examples.
Cross-functional alignment session
Design, development, QA, and product in one room, agreeing the shared rules and who owns what.
How the training is delivered
Training is live and instructor-led, delivered remotely or on-site, and it runs on your own product — your pages, your components, your workflows — rather than on abstract examples. Sessions are structured so the team can apply what it learned the same week.
Training can also be woven into ongoing design and development work, so the patterns are reinforced as features ship rather than taught once and forgotten.
The hands-on workshop, in practice
Teams rarely struggle because they lack awareness. They struggle because accessibility decisions happen inside real constraints: deadlines, design systems, legacy components, and tickets that are already scoped. A workshop meets the work where it is.
In a session we review your real interface patterns, run the checks live, and walk through what good looks like on your own screens — keyboard navigation and focus behaviour, screen reader behaviour and reading order, forms and errors, semantic structure, and interactive components such as menus, modals and tabs. Your team leaves with repeatable testing steps it can run without us, and fix direction specific enough that a developer can act on it.
Why role-based training beats one generic session
Generic accessibility training gives everyone the same rulebook, and most of it does not apply to the person reading it. Developers sit through design guidance, designers sit through ARIA, and nobody leaves knowing which part they own.
Splitting by role fixes relevance and ownership at once: designers prevent issues where they are cheapest to fix, developers implement consistently against specific criteria, QA catches what tools miss and reports it in a form developers can act on, and product and content stop introducing barriers through copy, media and documents. When each role knows its boundary, the same issue stops being rediscovered three sprints later by a different team.
Standards the training is mapped to
- WCAG 2.1 and 2.2, Level A and AA — the technical criteria behind ADA expectations and most enterprise requirements.
- Section 508, measured against WCAG 2.0 Level A and AA, the version the Revised 508 Standards incorporate, for federal work and vendors selling into government.
- Assistive technology behaviour — how screen readers, keyboard-only use, and magnification actually interact with what your team builds.
What your team can do afterwards
- Test a page or component without waiting for an audit, using keyboard, screen reader and structure checks the team can repeat.
- Write a finding that names the criterion, the impact and the fix, so tickets stop bouncing between roles.
- Recognise the failure patterns that generate most audit findings, before they ship.
- Apply one shared set of accessibility rules across design, development and QA.
- Hold accessibility steady through releases instead of rebuilding it after every audit.
Trusted by leading brands
We are proud of our customers
Common questions about accessibility training
How do we choose which course our team needs?
Who should attend accessibility training?
How is this different from a recorded course?
Does training guarantee compliance?
Can we train only developers, or only designers?
Is the training WCAG or Section 508 focused?
Can automated tools replace team training?
How soon will we see a difference?
Who does this work
David LoPresti's work centers on translating WCAG and Section 508 requirements into practical implementation and verification processes, and that is the same material these sessions teach. Your developers, designers, QA, and content teams work through the criteria against your own interfaces and components, so what they learn applies to the release they ship next.
The standards this page refers to
Train your team to build accessible products
Tell us who needs training, what they are building, and which standard you are held to — we will recommend the format and the sequence.
Schedule a consult (opens in new tab)