Product leadership & accessibility
MTX TOTA11y
Checking whether a website works for people with disabilities was spread across five different tools, and it always happened too late. I turned it into one browser add-on: find the problems while you build, agree on what to fix, and hand over proof — with nothing to install on a server.
The problem I chose to solve
Teams already had tools that could find accessibility problems. What they did not have was a way of working. Results sat in one tool, proof in another, and progress in a spreadsheet. Problems surfaced days before launch, every project handed over something different, and pop-up windows — where most of the real work happens in enterprise software — were skipped entirely.
I started from decisions, not features
I owned this end to end — the idea, the research, what to build first, and getting people to actually use it. I started by asking what each person needs to decide before a launch, then built only what answers those four questions.
Developer
Is the screen I just built good to go?
An instant check that points at the exact thing to fix.
Tester
Will this page pass a review?
A full check, plus screenshots that prove what went wrong.
Project lead
Can we launch, or is something serious still open?
A count of what is serious, and a summary they can forward.
Compliance
How far can we trust these results?
A written list of what the tool checks, and what it does not.
What I changed about the way teams work
Four points in the process where the old way was costing us time, and what replaced it.
| Moment | Before | After |
|---|---|---|
| Finding problems | Several tools, each reporting in its own way | One check, ranked by how serious each problem is |
| Pop-up windows | Skipped, because tools only looked at the main page | Checked like any other screen |
| Deciding what to fix | Tracked in a spreadsheet, far from the actual work | Owner, priority, and notes kept next to each problem |
| Approving a launch | A judgement call with little to show for it | Nothing serious left open, and a record of the exceptions |
The workflow I designed
Six steps, each with someone clearly responsible, ending in a launch decision rather than a report nobody reads.
- 01 Check 21 checks run on the page you are looking at Developer
- 02 See Problems drawn on the page, ready to screenshot Tester
- 03 Hear An early listen to how the page sounds out loud Tester
- 04 Decide Agree what gets fixed now and what can wait Lead
- 05 Share One click to a report, a summary, or a task list Lead
- 06 Approve Launch decision backed by something you can show Leadership
Four calls I had to make
Every one of these was a trade-off between what users wanted, what the business allowed, and what teams would actually adopt.
Where it lives
A browser add-on, not a website
It works right where teams already work, client data never leaves their machine, and there is no service to buy or run.
Considered A website teams log into Chose An add-on in the browser
How much it covers
21 checks, not 200
A shorter list people trust and act on beats a long one that buries the things that actually matter.
Considered Every rule we could automate Chose 21 people actually act on
The hard part
Pop-ups count as screens
Most enterprise work happens inside pop-ups and step-by-step forms, so I refused to treat them as an afterthought.
Considered Checking the main page only Chose Pop-ups checked as well
Being honest
New features labelled Beta
Teams get the benefit early, but anything unproven stays out of the official sign-off. Trust was worth more than the feature.
Considered Shipping it as finished Chose Labelled Beta, kept honest
Where I took it next
I planned each stage around a change in how teams work, not a list of features. That is what made it easy to agree on with leadership.
Now · Shipped
Anyone can get an answer today
The full workflow, a help site people can use on their own, and a trial run on real projects.
Next · Habit
It becomes part of every review
Built into how projects start and finish, with one consistent report clients can expect.
Later · Everywhere
Nobody has to be reminded
Rolled out company-wide, covering whole sites rather than one page at a time.
What it looks like in use
Four moments from the shipped product, each tied to a decision above.
An answer in minutes
A plain summary of what is wrong and how serious it is.
Turning findings into work
Each problem gets an owner, a priority, and a note.
Pop-ups included
Check the page, just the pop-up, or both together.
A report you can share
Filter, export, and hand the same list to whoever needs it.
I was not trying to build a better scanner. I was trying to change a habit: catch problems while there is still time to fix them, give everyone the same picture, and be honest about what the tool can and cannot promise.