Accessibility training for your team
Workshops on your product’s components and flows. Designers, developers, QA, content specialists and product owners work on role-based exercises and review the results.
Who is the training for?
Each role works on different decisions. We agree on the goals and depth; these examples show what you practise and what you prepare during training.
Designer
You design screens that make it clear what to read, where you are and how to interact without a mouse. You define component behaviour with development and QA, including errors and loading states.
- What you practise
- You annotate a form: reading order, keyboard navigation, focus indicator and error messages.
- What you prepare
- A component specification with states and instructions that development can implement and QA can test.
Developer
You build controls that work with a keyboard and expose their name, role and state to screen readers. You start with native HTML and assess when ARIA attributes or specific focus management are needed.
- What you practise
- You fix a field with an associated label and error, then test the keyboard form-filling journey.
- What you prepare
- A corrected component and a checklist to use during code review.
QA
You test whether a person can complete a journey with a keyboard and screen reader. You distinguish the observed issue from its impact and record the information needed to reproduce it.
- What you practise
- You reproduce a barrier in a form, write the issue report and repeat the test after the fix.
- What you prepare
- A bug report with environment, steps, expected result, evidence and retest outcome.
Content
You write content that helps people understand information and choose what to do, including when listening with a screen reader. You work on headings, links, instructions, images and tables.
- What you practise
- You rewrite a generic link and an error message, then choose alternative text for an image based on its purpose.
- What you prepare
- Annotated examples and an editorial checklist to reuse before publishing.
PM
You organise accessibility work across priorities, responsibilities and deadlines. You connect barriers to the actions they prevent and define what must be tested before a fix can be closed.
- What you practise
- You prioritise sample issues by impact and assign each an owner and testable acceptance criteria.
- What you prepare
- A prioritised list of actions and shared criteria for considering the work complete.
What happens during the course
We define the modules around what the team needs to learn to address and the cases they bring.
- 01
Practical foundations and user impact
A shared basis for understanding accessibility as product quality: actual barriers, WCAG criteria, role responsibilities and the limits of automated checks. Further references depend on the product’s markets; EN 301 549 and the EAA are covered when relevant to the programme.
- Materials: a map of essential concepts, a practical glossary, and examples of barriers and impact.
- Exercise: distinguish blocking issues, tool warnings and content problems.
- Output: shared criteria for discussing severity, risk and priority.
- 02
Accessible design and testable handoff
A session for UX/UI and product teams: information structure, headings, focus, states, components, errors, alternatives to colour, microcopy and annotations for development and QA.
- Materials: a design review checklist and component annotation framework.
- Exercise: fix a screen with a form, cards, menus and error messages.
- Output: handoff notes and acceptance criteria ready for the backlog or design system.
- 03
Robust frontend development
A technical session on HTML semantics, ARIA where needed, focus management, modals, menus, disclosures, live regions, form validation and regressions introduced by custom components.
- Materials: basic patterns for name, role and value, focus order, errors and dynamic states.
- Exercise: refactor an inaccessible component and define regression tests.
- Output: snippets, review criteria and baseline checks to integrate into the development workflow.
- 04
QA, screen readers and retesting
A session for QA and release leads: keyboards, screen readers, mobile assistive technologies, scanners, bug reports, evidence, retesting and the difference between automated coverage and conformance.
- Materials: a manual testing matrix, bug report template and retest checklist.
- Exercise: test a journey with a keyboard and screen reader, then write a reproducible issue.
- Output: a baseline verification plan and criteria for closing remediation work.
What you receive after training
Afterwards, you keep materials related to the modules completed and roles involved. We agree in advance on the exercises, checklists and templates to prepare, along with any follow-up.
Materials
Course materials and practical summary
Concepts, references and examples covered in the sessions, organised for the participating roles and available to consult after the course.
- A summary of the criteria covered and decisions discussed.
- Examples related to the components and journeys used during the sessions.
Exercises
Exercise outputs and review guidance
Work produced during the lab and guidance from the facilitated review, reusable in similar cases.
- Depending on the module: handoff annotations, snippets, bug reports or acceptance criteria.
- Discussed fixes and tests useful for verifying expected behaviour.
Tools
Checklists and templates for everyday work
Practical tools consistent with the completed modules, to bring checks into design reviews, development, QA and documentation.
- Depending on the course: review checklists, a bug report template and a retest plan.
- Checks and acceptance criteria to integrate into the team’s processes.
Draft workshop sheet — fictional example
- Status and audience
- Draft of a two-hour session for designers, developers and QA. The programme needs adapting; no session has taken place.
- Observable objective
- From a form with errors: an expected-behaviour specification, a reproducible bug report and a basic verification plan.
- Preparation
- Agreed participants and goals; demonstration form, browser, screen reader and materials ready.
- Proposed agenda
- 20 minutes: barriers and user impact; 25: guided demonstration; 40: exercise by role; 25: review of the work; 10: summary and next actions.
- Exercise
- Designers: states and focus. Developers: semantics and errors. QA: steps, expected result and evidence to collect.
- Planned deliverables
- Summary, reviewed exercises, form checklist, bug-report template and retest outline, to be prepared for the agreed programme.
- Learning assessment
- The review checks the barrier, impact, expected behaviour and verification steps. The draft contains no completed exercises or results.
- Next step to agree
- Choose a component for applying the criteria in everyday work and agree on any follow-up.
How we organise workshops and follow-up
Four stages, from the case to the next actions: preparation, agenda, summary and closure checks.
- 01
Before the workshop
We agree on a flow, an outcome to work towards and the roles involved.
- The product owner defines scope and constraints; I prepare the outline, materials and tools for the chosen case.
- We are ready when goals, participants and access are confirmed. Exercises use demonstration data, without real personal data.
- 02
During the workshop
An indicative three-hour agenda, including a 15-minute break, to adapt to the group and chosen case. The facilitator keeps time; a participant records decisions and open points.
- 20 min · Alignment: objective, scope and initial conditions of the case.
- 30 min · Guided example: barrier, user impact and expected behaviour.
- 60 min · Exercise: work in pairs or by role to produce a proposed fix with acceptance tests.
- 15 min · Break.
- 35 min · Review: compare proposals, distinguish observations from assumptions and assign actions.
- 20 min · Summary: confirm owners, deadlines and evidence still to collect.
- 03
Summary and deliverables
I bring decisions, exercises and open points together in a summary linked to the case we worked on.
- Course materials, reviewed exercises and guidance for reusing the checks on the product.
- Owners, next steps and agreed deadlines for outstanding actions.
- 04
Follow-up and closure
If included in the engagement, we review the fixes and evidence collected by the team.
- Closure requires a documented retest that meets the acceptance criteria. An implemented change does not equal a passed check.
- If work remains open, we confirm an owner, next step and deadline. Results remain limited to the checks performed.
Format, outcomes and continuity
Duration and programme are agreed beforehand. We choose modules around the team’s roles and cases; we also agree on the language of sessions and materials for Italian, US and international teams.
Workshops, guided reviews and follow-up
One to five sessions of 2–4 hours, spread over several weeks. Duration, roles and activities are agreed in advance.
Outcomes observable in the work
A reproducible report, an acceptance criterion or a review makes it possible to see what has been understood and what still needs work.
Office hours for teams already at work
Short meetings at agreed intervals to review pull requests, mockups, issues and fixes. Useful after a workshop or during remediation.
The service at a glance
Who it helps, what you receive and what to prepare for the initial discussion.
- When you need it
- For designers, developers, QA specialists, content teams and product owners who need to recognise barriers and integrate checks into everyday work.
- What I do
- We agree objectives and modules by role; work on examples, components and journeys through guided exercises and feedback on participants' work.
- What you receive
- Materials for completed modules, reviewed exercises, checklists and templates your team can reuse.
- What we need from you
- Roles, training needs, availability and usable product cases; access or documents for the agreed exercises.
- Scope
- Modules, duration, roles and exercises defined before the sessions. Training does not replace a product audit, release QA or usability testing with users, and does not confer conformance certification.
- How we continue
- Tell me who will participate and a recurring difficulty: we will agree modules and exercises. At the end, we review the work produced and checks to reuse in everyday work.
Templates and exercises
Practical examples and exercises in the Resources section for independent practice.
Frequently asked questions
Who the courses are for, how I prepare them and which materials the team keeps.
Who needs digital accessibility training?
Designers, developers, QA specialists, content specialists and product managers who need to design, develop, test and manage accessible digital products.
How long does training last?
From 1 to 5 sessions of 2–4 hours, with additional office hours at an agreed frequency if needed.
Do we work on my product?
Yes. Before the course, we gather real components and journeys from your product, and the exercises use those components rather than generic examples.
What does the team retain after the course?
Reusable checklists, acceptance criteria and materials that become part of everyday work: backlog, handoff, PRs, tests and documentation.
What would you like your team to be able to do?
Tell me who will attend and which difficulties they encounter at work. We use this to prepare workshop objectives and cases.