I identify barriers, help your team design fixes and verify the outcome. Audits, design, QA and training to make websites, apps and documents usable by people with disabilities.
Choose according to the decision you need to make: what to fix, how to design, what to test or which skills to develop.
When you need itYou have an existing product and need to understand which barriers to address first.
When you need itYou are designing a journey and want design, development and QA to work from shared criteria.
When you need itYou are preparing a release or need to check the outcome of fixes.
When you need itYou want your team to recognise barriers and check its own work.
I help you organise accessibility work on your company’s product with your internal team and suppliers.
We start with important user journeys and service constraints. I help you identify where to act; your company decides priorities and resources.
I clarify findings with those responsible for design, development and content, giving the people implementing changes actionable guidance.
We distinguish open issues, verified corrections and areas still to be tested, so you can decide on the next step.
I bring accessibility expertise to the projects you manage, from design through to retesting.
You retain project leadership and the client relationship. We agree when to involve me in technical discussions.
I clarify requirements and findings with design, development and QA. I adapt deliverables to the team’s tools; developers implement the changes.
If white-label work is needed, we agree on branding, confidentiality and how evidence is shared.
Fictional example: a catalogue barrier, the proposed fix and a simulated retest. It shows how I document the work; it does not report client results.
The QUOTIDIANO catalogue lacks a focus indicator. Case DEMO-F01 follows the same barrier from the report through verification of the fix.
Both controls are affected: in this demonstration the priority is high because choosing a product becomes uncertain.
The change affects the buttons’ :focus-visible state. The expected behaviour is documented in finding DEMO-F01.
In the simulated case, DEMO-F01 is closed for focus on the two controls. Payment, screen readers and catalogue-wide conformance remain out of scope.
Five phases, each with an outcome to hand over to the team. Support and retesting are agreed in the engagement.
Agreed scope and activities
Findings with reproducible evidence
Prioritised list of actions
Agreed solutions, if support is included
Correction outcomes, if retesting is included
Tell me what is happening in your project and what you want to achieve. If the right service is not clear yet, we can define it together.
