Accessibility: Access All Areas
Accessible digital experiences are something we strive for at Comic Relief — we’re not perfect at it, but we’re trying to make sure that we can embed inclusive design at the heart of our product development*. In this article, I’ll be sharing some of the peaks and troughs of our accessibility work and the progress we’ve been making to ensure our digital experiences are accessible to all users.
Commissioning accessibility audits
Step one was commissioning audits from accessibility experts. In 2016/2017, we used AbilityNet to test our journeys. We received a lot of feedback and dedicated some time in early 2017 to make improvements.
Roll on November 2017, we enlisted the help of the Digital Accessibility Centre (a not-for-profit based in Wales), who did our next round of testing. What’s really fantastic about DAC is that they hire testers with disabilities to perform the testing, and allow members of your team to observe as the testers put your products through their paces. On arrival at the centre, I was so certain we would have a glowing report with a few minor tweaks — I really believed that we were in a good position with our work. I was in for a shock!
The irony of having an inaccessible Accessibility link in the footer of Sport Relief’s website, is not lost on me. It was one of the things that stood out most to me in the 190 page report from the DAC. It was clear from this that if we wanted to strive for AA and AAA standards for our digital experiences, we were going to have to commit a lot more time, effort and focus on accessibility in our work.
Retro-fitting accessibility best practices
If I could go back and change one thing about our work since I joined Comic Relief, it would be to prioritise accessibility work earlier. Our products are now in pretty good shape in terms of stability and reusability, but we’re now having to retro-fit accessibility fixes into existing code. This is much more time consuming than if we had inclusive design and best practices embedded in our ways of working from the start.
This is not a mistake I intend on repeating, which is why we’ve formed a group who are collaboratively creating an Accessibility Manifesto — an artefact to be referred to, evolved and embedded in digital product development going forward.
Communicating the value of accessibility work
While everyone can, in theory, see the benefit of accessible digital experiences, it can be difficult to communicate the value. Like many digital product teams, we are faced with a tension between delivering shiny new features and improving current systems. The fact is, on the surface, accessibility work just isn’t very sexy…
Aside from the obvious added value to the charity (like usable e-commerce websites), our team are also demonstrating the potential innovation which accessibility work can enable. Luckily for us, there’s nothing that stakeholders love more than AI and Personal Assistant Tech!
By drawing comparisons of how users who rely on voice-controlled assistive technology (such as Dragon) interact with our products with personal assistant applications (like Siri), we’re able to make the seemingly unsexy work suddenly much more attractive to stakeholders.
Finding relevant best practice examples
WWGDSD — What Would GDS Do?! Has become a bit of a mantra for me when researching best practices. However, with all due respect to the Government, some of their digital experiences are a liiiiittle dry! As we know that our digital experiences will never be gov.uk, we need to seek alternative best practice leaders who offer more comparable experiences to Comic Relief. The BBC are a longstanding partner of Comic Relief and they have some useful documentation about their accessibility processes and implementation. Looking further afield, Microsoft’s Inclusive Tool Kit Manual has become a real go-to for finding examples of best practice. It’s also a great example of a brand which still needs to be entertaining and engaging, as well as inclusive and accessible. If you haven’t checked it out, I thoroughly recommend to a friend!
Testing in-house with assistive technology
As we implement more fixes (as per the aforementioned 190 page report…) , we’re trying to upskill our team so that we’re able to test in-house rather than depend on external testing. We intend to invest in additional testing software, such as Jaws or Dragon, so we can set up an accessibility lab and also to demonstrate assistive technologies to the wider organisation.
Free tools like ChromeVox screen readers are quick to install and can get you started with in-house testing, you can easily uncover issues which are big wins in usability. For example; navigating using a keyboard and screen reader can identify if your page has appropriate tab orders — if it doesn’t you’ll be jumping round the page and getting the information in a jumbled order.
While in-house testing is speeding up our delivery of improvements to production environments, we will still use external testers like DAC to make sure that we are regularly testing with native users of assistive technologies. From observing the testers at DAC, the behaviours of native users (like out-of-context navigation with screen readers) are skills and experiences which we currently can’t replicate in-house.
So, what’s next?
Well, there’s still a fair-few tickets to complete from the previous DAC audit, but we’re hopeful that retesting in early February will result in a slightly shorter report! An area where we knew we’d need to make improvements was the experiences users have when transitioning across our sub-domains — whether on our giving pages, sportrelief.com or the shop, users of assistive technology should have a consistent experience. We use reusable code in our work — such as the pattern lab — which means that many of our updates can be applied across multiple products at once. As well as the Accessibility Manifesto (to be shared on the blog soon), there will also be updates to the engineering handbook so that we can establish consistency for users across all our products.
*Nothing makes you more nervous than writing a long article about accessibility on a blog platform which you are not 100% certain is accessible.
