Getting started with web accessibility can be tough. There's so much to think about, so much to try and understand and no clear definition of done. Where do you start? How do you keep on top of it? And how do you know if you're doing it right?
Before I jump into exploring these questions, I want to talk a little bit about my journey into web accessibility.
How it began
A long time ago in a metaverse far, far away....
I was working as a web consultant at the Open University. Now, as a publicly funded body with a mission statement of "open to people, places, methods and ideas", they had a strong obligation to make their digital resources accessible to as many people as possible.
At the time I faced a real conflict, because web 2.0 was kicking off in a big way. New technologies and tools were accelerating web experiences into places they'd never gone before; CMS platforms, AJAX, modal popups, drop-downs, video players - all very exciting stuff. Except... every time I got excited about using these things, I was brought crashing back to earth because I was told they "weren't accessible enough".
I was frustrated to see global players using all of these technologies that we could not use to our advantage. Being a small, enthusiastic team with aspirations to deliver great digital services for students, yet shackled by our restrictive choice of options, it felt like we were stuck between a rock and a hard place.
Enter Gov.uk.
When Government Digital Services relaunched their website, it changed my outlook on web accessibility completely. Here was the most bureaucratic and complex organisation in the whole country, delivering a world-class digital service that unbroke all the rules. By stripping back all the layers of complexity that the web 2.0 movement had gradually piled on, they tapped into the accessible-by-design nature of the web again. (It sounds so obvious when you look back!)
The realisation that the web wasn't something we needed to try and make accessible, but something that is accessible, was liberating. Now don't get me wrong, there's no silver bullet — and we still had many problems to solve. But rather than starting with a complex set of technologies and endlessly chasing accessibility issues around, we shifted our focus to leverage the HTTP request/response cycle and semantic markup that the web was founded on. Favouring progressive enhancement over plug'n'play solutions and taking pride in knowing that we were building something inclusive, not just new and shiny.
And I lived happily ever after. The end.
Well, not quite. It turns out this was only the beginning and there was a lot more to learn.
What I've learnt
Fast forward several years and I can tell you that web accessibility, just like UX, is a reflection of society; it's messy, illogical, conflicting and has endless needs — but done well will provide many inclusive design benefits.
I've learnt that there's loooads of WCAG criteria to understand, a whole range of different best practices, incomplete specifications and a whole spectrum of differing user needs. In other words, there is no easy or perfect solution. But there is hope. And a way. And it's worth it.
In just a few years, accessibility support across the board has improved significantly — there's better tooling available, better standards across browsers and assistive devices and many leading software libraries have started to become more accessible as the demand grows.
Where do you start?
Becoming better at accessible design should be seen as a journey of improvement. There's lots to learn, awareness to raise and problems to solve. So my secret? Start off small, find an issue, learn how and why to fix it and then keep going. As your knowledge improves, you will find you start to bring that knowledge to the design process earlier on. To help you get started, I've compiled a list of steps you can take right now to start your journey.
1. Choose a sample
It's not practical or particularly useful to test every page of your website, so pick a representative sample of key templates and pages.
The sample should include:
- Homepage
- Listing pages, like categories
- Content pages
- Navigation pages, like sitemap or search
- Interactive tools / transactions, like forms
- Accessibility pages
- Legal or policy pages
- Contact pages
- Settings or preference pages
If your site is particularly large, perhaps limit yourself to 3-5 key pages to start with. And remember, because you are using a sample, when you find an issue, make sure to fix all instances of it across your site.
2. Run automated tests
Automated tests won't catch every issue, but they are a fast, repeatable way to catch low-hanging fruit. Tools like Chrome Lighthouse and axe DevTools are a good starting point for this.
Make sure you resolve the issues found by the tests before you move on, as often these issues end up being the root cause of other issues.
3. Perform fundamental manual checks
There are plenty of things that cannot be tested automatically. The problem is that manual checks take time.
To help you get an idea about what to check, I'd recommend looking at W3C Easy Checks and The A11y Project Checklist. Both of these can also be used as a guide for more comprehensive checks, so use your judgement to choose what you want to focus on. It's about getting coverage and identifying the areas of greatest impact.
A good starting point might be to pick some fundamental checks that can be repeatedly performed quite quickly (a few hours to a day). I'd recommend including things such as page titles, primary navigation, page structure, keyboard navigation, link styles and zooming. These are non-content specific and typically span the whole of your site.
Don't worry if it takes some time to begin with, you are learning and will be able to reuse that knowledge in the future.
4. Perform comprehensive checks and build solutions into your design process
Comprehensive testing means getting deeper into the content of your site. Remember, you're not trying to test every piece of content, just different content types. This can be quite time consuming and is not something you can realistically keep repeating often.
Ideally, you want to capture your outcomes from this sort of testing so that they can inform your design system and content strategy. For example, if you've dedicated time into reviewing a form, it would be beneficial to try and build the learnings from that into the way all your forms are designed and built.
Try not to get too obsessed with one single issue, sometimes a lateral solution is often the best, and keep in mind that accessibility is about enabling people — so try to think about it from their perspective when you can.
Need some help?
We've been tackling web accessibility for many years and can most likely help you. From our super-charged accessibility reports, to embedding ourselves into your team, we have a wealth of experience and we're ready to help you.
Get in touch if you'd like to talk to us about your accessibility challenges.
Feel free to connect with me on LinkedIn if you'd like to discuss this further or ask me any questions.
About the author
Hey, I'm Ben - a digital consultant / full-stack web developer with over 20 years of experience.
I've worked across a number of industries including telecoms, education and energy management and am always keen to bring my experience to new industries and business types.
My ability to blend technical knowledge with business acumen allows me to develop intelligent and sustainable solutions that deliver business value, increase productivity and reduce costs.
I work well in teams, whether coaching, collaborating or leading and understand the importance of stakeholder engagement, communication and planning.
My preferred technology stack is PHP / Laravel, Livewire, Alpine.js and Tailwind CSS, but I'm also well positioned to help businesses migrate from older technologies that may be holding them back.