I’ve been on quite a journey over the last 12 months with digital accessibility. I thought I knew a reasonable amount about it. From a design perspective I’d check colour contrast ratios met WCAG guidelines and our coders use semantic mark-up and check their code passes automated accessibility testing tools. But I wasn’t sure that was the whole story. Being an active Tweet consumer of all things UX and digital, following the good work being done around accessibility at organisations such GDS and the BBC it sounded like there was a lot more to it. Hence I arranged to have an accessibility audit done as part of a project I was working on. This was the start of my journey to understanding what web accessibility really is. Realising why accessibility is part of the whole design process and not just something that can be tagged on at the end of a project to ‘make it accessible’.
The accessibility audit
The accessibility audit took the form of accessibility experts checking the website using an automated test tool such as WAVE and manually checking the journey using screen readers on desktop and mobile. NVDA was the screen reader used on desktop and iPhones inbuilt VoiceOver on mobile. Some issues were identified using WAVE but the main findings came from the manual screen reader testing with issues ranging from critical ones where a user is unable to perform a task to minor issues that may frustrate the user but won’t stop them doing what they need to do. The accessibility audit was really the first step in highlighting the issues to the team and the start of a learning curve in how to design and develop accessible digital journeys. It gave us the starting point to fix the main issues identified by the audit.
Learning curve
The audits kicked off the process of the team learning how to use screen readers which seems a bit tricky at first and but once you’ve got to grips with using them it becomes apparent if there are any issues in navigating the page, using interactive features and finding content. Then you can start to test code using assistive technology during the development process. With multiple agile teams this takes time to disseminate learnings and best practice.
Getting to grips with the Web Contact Accessibility Guidelines (WCAG) is also daunting at first and it’s easy to get over whelmed by the level of detail you can get into on any one aspect of accessibility such as the humble alt tag. But like anything you need to start somewhere and you get better at it as you go along. I’ve found it an addictive subject that once you get into to it you want to learn more and more about it. The WCAG Quick Reference provides bit sized information on accessibility success criteria and how to achieve them. There are many other great resources out there that provide a high level introduction to some of the main things to check for accessibility and provide a gentle way into the WCAG, I’ve listed a couple below:
https://accessibility.18f.gov/
Inclusive usability testing
So the accessibility audit has been carried out and the main issues fixed. You’re now confident that technically everyone can use your website and do what they need to do. But can all users do that easily with the minimum frustration and understand everything they need to? You’ll need to test with real users to help answer that question and your user’s will more than likely include people with accessibility needs.
I recently observed some usability testing with an older age group and the majority of the participants squinted and moved closer to the screen to read it or got out a pair of reading glasses. This emphasised the need for larger text and good contrast more than any guidelines. On a different occasion talking to one blind user he said one of the main things he wanted as part of an application or purchase journey was a summary of all the information he had entered and choices he had made so he could check they were correct. Using a screen reader he often felt uncertain if had entered information correctly or had chosen the right options. Something like this is crucial to making a product or service accessible and is part of how it is designed. This wouldn’t be picked up by automated accessibility test tools, they would need to be understood as part of inclusive design principals or picked up as part of inclusive usability testing.
