Tell us about yourself and your work!
I'm a freelance digital accessibility specialist, based in London. I work with individuals and with teams to help them to make digital products that work better for people.
The thing I'm most known for is my work with the UK government. I helped to create the prototype of what became the GOV.UK website became one of the founder members of the Government Digital Service (GDS), then created and led the accessibility programme across the digital transformation programme GDS lead for a number of years.
Since leaving government I've focussed on accessibility and inclusive design consulting, occasional bits of development, various service design and prototyping projects. I pigeonholed myself pretty well with the accessibility work, so I try and make sure I keep learning.
What qualifications do you have that have influenced your work, if any?
Nothing from an educational point of view, really. I didn't attend university and I never studied computing in any real capacity besides a few months in a technical college during 1990-'91. I'm self-taught and I've been lucky to work with some incredibly smart and generous people over the years who have helped me fill in the bits I don't know.
I've always loved learning how things work and how they fit together, and I've had a lot of luck because of being willing to work hard and to take chances on things I didn't really feel qualified for at the time. Being organised, being curious and being flexible have been better drivers of my career than anything I did at school.
Why accessibility? What does accessibility mean to you?
"I like to include people, I don't like bullies, and I think that caring about things like accessibility is a marker for the pride you take in the work you put out there."
If you call yourself a professional working on the web, you have a part to play in making more inclusive products regardless of whether it's already a focus of your organisation or a part of your role.
Working on the web is a fairly transitory thing most of the time. What we build doesn't tend to stay fixed in time for very long; with the possible exception of the Space Jam website, what we put out there is rarely the same months let alone years later.
When everyone is more focused on chasing trends or on The Next Big Thing it's easy to forget about the humans on the other side of the screen, just trying to do a task that's important to them. I do this because it annoys me that the people making your business possible are forgotten about too often.
Having worked on many different levels of a career ladder, how has your approach to accessibility changed over time?
If anything, my focus has gotten sharper on just doing the basics right.
I tried to cover too many things in the beginning. "Everything is broken, so we need to fix everything!" You soon learn that spreading yourself too thin is a recipe for burnout and for dissatisfaction. You have to pick your battles with this work, and sometimes you're going to have to try and move things forward while the organisation is telling you that they don't care about it.
Small, incremental change in the right direction builds up. Even if you're just making things 1% better than they were yesterday, you're making things better in measurable ways for the people trying to use your products. Slow and steady wins the race.
When an organisation approaches you for consultation on integrating accessibility into their team, what are the typical catalysts for change?
If it's a team outside of the US, it's usually because they're trying to differentiate themselves more in the marketplace and they recognise that inclusive design and accessibility is too important to ignore.
If it's American, or if the team is trying to do business there, it's more often because they're being sued and want to show that they're doing something about it. Fear of legal is a much more important driver than wanting to do the right thing.
A lot of teams, even if they're used to working in an agile way, don't really understand how to include accessibility into a sprint-based delivery plan and need some help from someone who's done it before.
What are the typical catalysts when an organisation comes to you to help integrate accessibility into their team?
Legal requirements? A champion? Company culture?
Aside from the things I just mentioned, there's usually just a desire to try and do better and to learn from someone else's experience of doing this a few times. It might be a specific product that they need help with or a specific feature. It might be a strategy to integrate this kind of work into an organisation or a team. Part of the fun of being a freelance consultant is that it's usually different in each situation.
And what would you say to someone in an organisation eager to have you help them but their bosses aren't buying into the value of accessibility?
Don't think of it as a process you can bolt on at the end that only affects testing. Done well, it raises the bar for quality in your entire organisation. But start small with something you know you can deliver, then build on that success to demonstrate that it doesn't need to slow your velocity or complicate your delivery - it's just another part of making your products better for a wider audience.
I use the argument of producing products that are cheaper to build, cheaper to test, cheaper to operate and much more robust for a wider range of devices long before I start talking about accommodating users with disabilities.
If you're not winning the argument about disabilities or supporting assistive technologies, don't make it just about that. The work you do specifically to help users of assistive technologies like screen readers is helpful, sure, but throwing a few ARIA roles on top of some terrible div-soup HTML foundation isn't a long-term strategy for success.
What one bit of advice do you find yourself saying over and over again?
It's a cliché, but doing this work is a marathon, not a sprint.
You can't make products that work for 100% of people 100% of the time, but you can make measurable improvements to your products to make them more robust for a broad range of people in a broad range of situations. Those improvements - things like better semantics, like better design, like better content - just happen to help users who also need a little more help because of how they have to interact with your product.
Doing this work makes such a difference to people. It's often exhausting, often invisible, and it's too often framed as a hindrance rather than a help. But when you get it right it's such an amazing feeling that it makes the hard work worth it