Can everyone sign up and check out?

I find what stops people finishing the important tasks in your app, fix it in your code, and check back so it stays fixed.

Some people use a keyboard instead of a mouse. Some use a screen reader that reads the page aloud. Some zoom in a long way. If your sign-up, checkout or an important form doesn't work for them, they leave, and you rarely hear about it.

Automated scanners help, but they can't tell you whether a real person can get to the end. That's the part I focus on.

Real tasks

The whole sign-up or checkout, not just one page.

Clear proof

Every problem comes with steps to see it yourself.

Real fixes

Changes in your own code, with tests.

Honest gaps

Anything I couldn't test is written down.

It works for most people. That's not everyone.

People get stuck on a key task

Sign-up, checkout or an important form can't be finished with a keyboard, or a screen reader gets lost halfway.

A scanner report you can't act on

Hundreds of warnings, no idea which ones actually stop a person, and no clear place to start.

Pop-ups and live updates confuse people

After a dialog opens or part of the page updates, keyboard users land in the wrong place and screen readers say nothing.

Fixes that didn't stay fixed

Someone cleaned things up once, then new releases quietly undid it because nobody checked again.

It suits product teams and agencies who want practical engineering help, not a badge. Rails and Hotwire apps are where I'm most at home, and I also work with React front ends and Shopify themes.

Find the problems, fix them, keep them fixed.

Start with a review. Fixes and check-ups are there if you want them, and your team can always take the report and do the fixing itself.

Accessibility Review

01 · One key task

Find out what stops people finishing it.

I go through one complete task, like signing up or checking out, from start to finish, including the error and success screens. That's usually five to eight screens.

How I check

  • Automated scans first, then by hand: keyboard only, zoomed in, and filling in forms wrong on purpose.
  • The screen readers we agree on, such as VoiceOver on a Mac and NVDA on Windows. I note which versions I used.

What you get

  • A clear report: each problem, how to see it yourself, who it affects and how badly.
  • What to fix first, and which WCAG 2.2 guideline each problem relates to.
  • A list of anything I couldn't test, and why.
  • A call to walk your team through it.

Fixes aren't included; that's the next step if you want it. A review is not a certificate or a legal sign-off.

Accessibility Fixes

02 · The problems we agreed on

Fix them in your own code.

We choose which problems to fix and agree what "fixed" looks like before I start.

  • Changes go on a branch in your repository, with tests, so your team can review every line.
  • Your team decides when to merge and release.
  • Afterwards I go back through the same task to make sure it really works now, and that nothing nearby broke.

Parts you can't change, like a third-party payment widget, are listed with who to ask. They're not quietly skipped.

Accessibility Check-ups

03 · Every three months

Keep it working as your app changes.

New releases can quietly undo good work. Every quarter I go back through the same task, within an amount of time we agree up front.

  • What's still fixed, what broke again, and anything new.
  • Proof for each one, so nothing is guesswork.
  • What to do next.

It's a scheduled check-up, not round-the-clock monitoring. Each one is agreed separately, and nothing renews automatically.

Follow the task. Show the proof.

  1. Agree the task. We pick the task that matters most and agree exactly which pages and accounts I can test.
  2. Check it properly. Scans, keyboard, zoom and screen readers, with notes on what I used.
  3. Fix what matters. Changes in your code, reviewed by your team.
  4. Check again. The same task, so you know it's really fixed.

Your permission first: I only test the pages and accounts we agree on. A test account with limited access is best.

Nothing guessed: scanners flag possible problems. I check each one by hand before it goes in the report.

Honest about limits: I'm an engineer testing with screen readers, not a panel of disabled users, and I won't pretend otherwise.

No AI on your data unless you say yes.

Things people usually ask.

Will this make us compliant?

Not on its own. A review of one task isn't a certificate, a full-site compliance statement or legal advice. It shows you what stops people finishing that task, with proof, and what to fix first.

Our scanner shows zero errors. Aren't we fine?

Not necessarily. Scanners catch things like a missing label, but they can't tell whether someone can actually finish a task with a keyboard or a screen reader. I treat scanner results as hints to check, not as the answer.

Does the review include fixes?

No. Fixes are a separate step, agreed once we know what the problems are and which parts of the code you can let me change. Your team can also fix things itself using the report.

What kinds of apps do you work on?

I can review any web app I can open in a browser. For fixes, Rails and Hotwire are what I know best, and I also work with React front ends and Shopify themes.

Do you use AI tools on our app or data?

Not unless you say yes. And anything an AI tool suggests is only a hint until I've checked it myself.

How do we get started?

Email me the task that matters most, where people get stuck, what your app is built with and which parts your team can change. I'll suggest what to check. Everything is agreed in writing before I start. Please don't send passwords or customer data.

What should people be able to finish?

A sign-up, a checkout, an important form. Start with one task and tell me where people get stuck.

Helpful to include: the task, a link if you're allowed to share it, what the app is built with, which parts you can change, and your timing. No passwords or customer data, please.