When I tell people I work as a digital accessibility consultant I’m often met with a blank look, so I follow up with:

“I work with organisations to make their websites and apps work better for everyone, particularly people with disability and different access needs. I do audits, run training sessions, facilitate usability sessions with diverse users and work with designers and programmers.”

Once people understand, responses are typically along the lines of:


“I’ve never heard of that before.”

“That’s so great.”

“How noble of you.”

“That must be so fulfilling | inspiring | meaningful | rewarding!”

“Aren’t you good, to be doing that?!”

I get that these are throwaway lines. The person is processing a new concept, a job they’ve never heard of, so they say the first thing that comes to mind. On the other hand, I’ve had plenty of time to think about these responses. The more I mull on them, the more uncomfortable I get.

No one ever described my work as noble or inspiring when I used to introduce myself as a programmer, a technical architect, a user experience consultant or a technical writer. I still use all these skills in my current role, the only change from then to now being the increased focus on inclusion. My decision-making at work is now driven by accessibility, readability, usability, do-ability, whereas these used to rank a distant second behind “build the thing”.

I do challenge assumptions about users’ interaction patterns, education levels, physical capabilities and technical proficiency. I do raise awareness of different ways of thinking, perceiving and using, and how that could affect the take-up of a new website or app.

I don’t consider what I do as particularly inspiring. In fact, I think it’s a shame that my job exists at all. However, since it does exist, my aim is to do my job so well that I make myself redundant.

What does it say about the privileged nature of the information technology sector that many in it are genuinely surprised that not everyone uses a mouse/trackpad to interact with their computer?

The reactions also remind me of Carly Findlay discussing being called “inspiring” in her recent book, Say Hello:

I know that people who call me an inspiration are well intended. They think that it’s a compliment. But for me, and for other disabled people, the word “inspiration” can be tricky. Non-disabled people often call us an inspiration for doing not very much. That’s because expectations of disabled people are so low.

I am happy to inspire non-disabled people to think a different way – broadening their perceptions of what it means to be disabled. But I don’t want to inspire non-disabled people because they think my life is worse than theirs.

In a much lesser but similar vein, people shouldn’t think my job is inspiring because I work with and on behalf of people with disabilities. Instead, I want to inspire people to learn how to design and build websites and apps that better support the many ways that people consume and interact with digital content.

Don’t get me wrong; I love my job and I’m proud of what I do. I acknowledge that the recommendations I make and the issues I insist on having fixed are improving small corners of the online world. I just don’t think people would be so effusive if I described myself more generically as an IT standards assessor (hello, Web Content Accessibility Guidelines).

Considering the needs of people with disabilities and diverse access requirements doesn’t make me special – it should be the norm. Here are some things you can do to normalise a more inclusive web.

Encourage diverse hiring practices. Broadening your workforce will challenge long-held assumptions about design, interaction, information architecture and ways of working. It will also highlight the importance of having accessible internal tools as much as creating accessible external products.

Invite people with disabilities and different access needs to participate in your IT projects. Get broad feedback on your designs and prepare to be challenged. Run usability sessions and invite the whole project team to observe the different ways people use their product. Pay for their time and valuable insight.

Learn about the most common digital accessibility issues. Understand how and when to label images (and start doing it in Twitter, too). Use your site with a keyboard to appreciate the importance of keyboard support, visible focus styling and focus management. Use the Chrome Accessibility pane and the Firefox Accessibility Inspector to check what element labels, types, values and properties are exposed to assistive technology. Use readability tools, colour contrast checkers and accessibility test libraries.

Dive deeper. As daunting as it may seem, read the W3C’s Web Content Accessibility Guidelines, the Accessible Rich Internet Applications (ARIA) specification and the ARIA Authoring Practices. Attend meetups and conferences about inclusion to share experiences and learn. Get expert advice – and expect to pay for it.

Change the way you work. Don’t have a separate “accessibility” line item in your project plan. Instead, infuse inclusion into all your tasks. Requirements, user experience and service design, content writing, development, testing, everything should incorporate accessibility.

Don’t be scared. Yes, at some point you’ll say the wrong thing. Yes, you’ll incorrectly assume something about the way someone perceives or uses your site. Yes, it takes a long time, and there’s always more to learn. No, you can’t possibly know everything. Don’t stop trying. Be humble. Listen sincerely. Keep seeking feedback. If someone corrects your understanding of their lived experience, apologise and thank them.

Start today. I can’t wait to be out of a job and have an inclusive digital world to enjoy.