Foundations setup
Colours, type, spacing and icons chosen together, so you build the right way from the start.
- For
- Brand and product teams starting or refreshing a product
- When
- Before the design system exists
Audit what you've shipped, resolve what hurts users most, and train your team so it doesn't come back.
Get in touchWCAG 2.2 AA testing for websites and native Android and iOS apps — every issue evidenced and mapped.
Findings sorted by how much they hurt users, with fixes your designers and engineers can act on.
Designers and PMs who catch issues long before they reach code.
Accessibility should not be an afterthought.
I'm a product designer to the core — accessibility came later. So I don't stop at telling you what's broken. I help you design it right, from the first colour you pick to the app already in your users' hands.
Colours, typography, spacing and icons chosen with accessibility built in — before a single screen exists.
Menu 01 →Once it's built, every token and component is checked for contrast, target size and the basics.
Menu 02 →First prototypes get tested for usability and accessibility — and I help fix them, not just flag them.
Menu 03 →A full audit. Engineers fix the current version; designers remediate the next release.
Menu 04 →Training runs alongside all four stages, not after them. Designers learn to set up accessible foundations, build accessible components, catch issues in prototypes and fix what an audit finds — so the next product starts right without needing me in the room.
Menus 05–07 →Already shipped? Most teams first call me at stage 04. That's fine — the audit shows which earlier stage the problems started in, so we fix the source, not only the symptoms.
Pick one, or pair a few. Each offering says who it's for and when it fits.
Accessibility built in while you design.
Colours, type, spacing and icons chosen together, so you build the right way from the start.
Make the accessible choice the default one.
Not just an audit — a designer who fixes it with you.
For products already in users' hands.
Find every barrier, then fix it on two tracks — this release and the next.
Step 1 · The audit
Step 2 · Remediation
So the next release doesn't repeat the last audit.
A few protocols that prevent the most common pitfalls — no WCAG deep-dive needed.
Hands-on workshop · 5 hours
Design, annotate and review your own work like an auditor would.
Workshop series · Full day
Put a number on inaccessibility, then decide what to fix first.
Workshop · 3 hours
Tell me where your product is today. I'll suggest the one or two items from the menu that will make the biggest difference.
CPACC-certified and an invited expert at W3C's Mobile Accessibility Task Force — the body translating WCAG for native mobile. That background means findings come with the standards context your team needs to act, not just a list of things that are broken.
Every audit produces a SUC-scored priority list — now, next, later — so your team works through what hurts users most first. Remediation guidance is written for developers, not auditors, so nothing sits in a backlog because no one knows how to action it.
I help shift accessibility upstream — to the start of the product lifecycle. By equipping Product Managers and Designers with the right tools, we move from endlessly patching to designing it right the first time.