Skip to content


Over the past year and a bit, I’ve written quite a lot of help documentation about accessibility-related things. I’ve covered: Process, Design reviews, Auditing, Testing, and User Interfaces and Patterns.

I would watch for patterns in questions and audit results, and write up docs to address these things.


Getting a feel for how teams are working, questions they seem to have are:

  • how do we “do” accessibility?
  • how do we know if we’re doing a good job?

What to do when

Some teams look for clarity on “what to do when”: what activities should we be doing, and at what point in the process should we be doing them?

Measuring and metrics

Product people often want metrics, or measurements. Thinking about Measuring accessibility and how “100% accessible” is impossible I focused on leading (rather than lagging) measurements.

Design reviews

I’m a strong believer in the power of shifting left. Catching potential issues at the Design stage is better than catching after things have been built.


I have a confession to make: I enjoy auditing. I think this makes me a little unusual (but I’m okay with that). I like doing detailed analysis of a UI. I really like being able to suggest fixes, and showing the impact of the fix on our customer’s experience.

The process

Over the months, I’ve refined, revised, and standardised our audit process. The mobile one is still a bit in flux.

The results

Presenting the results of an audit can be tricky. It’s not helpful to make it a blame game or just a big list of problems. Some ways to make it a bit better are to be clear on the severity of issues (to help teams prioritise) and being clear and consistent.

Compliance and standards

I am in the accessibility business for the people, for making human-centered things. I prefer the carrot to the stick. But, sometimes we need to talk about compliance, and WCAG.

Quick checks

Audits can be a big deal. They feel heavy for the team receiving the results, and they can be time-consuming for the team doing the audit. To soften both of those, I thought about “mini-audits”.


For now at least, automated testing can only find some issues. We need manual, human, testing to find the rest.

Automated accessibility testing


Testing with the keyboard is by far the best “value for money” when doing accessibility testing. A good keyboard-friendly interface helps power users, keyboard-only users, screen reader users, and more.

Screen readers

Screen readers can seem intimidating at first. But they are a really powerful way to test our UI.

User Interfaces and Patterns

I’ve written a few things about working with a design system, and about specific UI patterns that crop up. Sometimes I throw together a reduced test cases and add it to my list of a11y demos and tests.


Writing alternative text for images can feel tricky. I wrote up a guide with some worked examples.

A quick guide to text alternatives for images

Data visualisation