Accessibility clinics: building software that works for everybody
Matt Eason, Lead DeveloperAt Fivium we’re dedicated to building software that works for everybody, regardless of any disabilities or impairments. We take this responsibility very seriously, especially because we’re often building services that people rely on every day to get their jobs done.
- They raise the profile of accessibility throughout the company. We extend an open invitation to anyone who wants to sit in and watch. This is important because everyone has an important role to play. Of course designers and developers are key in actually implementing accessible features, but project managers need to make sure that accessibility testing is factored into project plans, QA analysts need to know how to test for accessibility, content writers need to write accessible content, and so on.
- Empathy is a strong motivator, and developers actually seeing how their service works with accessibility tools used by our users goes a long way towards helping them understand the real-world issues those users face if the service isn’t accessible.
- Getting immediate feedback on how to solve the issues we find helps people get it right the first time next time they’re building something similar, and helps them spread that knowledge through the team.
Building accessible services requires thoughtful development and testing, and if you’re not careful it’s easy for issues to slip through the net. We have several layers of accessibility tests, including automated testing against WCAG 2.1 AA criteria, but we’ve found accessibility clinics to be one of the most useful for finding issues and spreading awareness and expertise of how to build accessible software.
Credit where it’s due: we adopted the idea of running accessibility clinics from GDS. We attended a GDS accessibility clinic when we were building the ‘Create an energy label’ service for BEIS. We came away from the clinic with only a couple of minor issues, but we thought it was a great idea that our other projects could benefit from, so we started running our own sessions in-house.
How our accessibility clinics work
Because GDS’s clinics cover the whole of government, they rely on teams signing themselves up via a Google Sheet. We’re much smaller, though, so generally people will come directly to me or I’ll identify projects which I think could benefit from a clinic and talk to the team about when we should slot them in.
Usually we have a weekly one-hour slot scheduled in our largest meeting room. However, due to COVID-19 we’re all currently working from home. This doesn’t stop us from doing accessibility clinics, though. We do video calls with screen sharing. It’s possible to share the audio from your computer so that everyone can hear when we’re testing with a screen reader (There are instructions for how to do this in Microsoft Teams and Zoom).
Each clinic is attended by the designer(s) and developer(s) responsible for the thing we’re looking at (the thing might be a new or updated feature, a set of screens, or a whole service if it’s small enough) and a QA analyst. We also announce every clinic in Slack with an open invitation to anyone else who’s interested, even if they’re not working on that project; we find that learning from real-life issues like the ones we uncover in the clinics is a good way to spread knowledge of accessibility testing techniques and development practices.
During the session, a member of the project team notes any issues we find. After the session they publish the notes for the rest of the company to see and raise the issues as Jira tickets ready to be fixed in a later sprint.
We try and cover a broad range of accessibility needs in the sessions, using these tools:
- axe, which runs automated tests to help check we’re conforming to WCAG 2.1 AA.
- Keyboard-only navigation, to make sure we’re accessible to people who don’t use a mouse (this could be for a variety of reasons, including physical impairments such as carpal tunnel syndrome or tremors, and visual impairment).
- Screen readers, such as NVDA and JAWS, which may be used by people with vision loss.
- Windows high contrast mode, which changes the colours on the screen to make text easier to read and removes distracting elements like background images.
We don’t currently cover voice recognition software such as Dragon in these sessions, but we do test with it as part of the QA process.
Is it worth it?
Absolutely, yes. It’s important to remember that accessibility clinics aren’t a substitute for doing user testing with people with accessibility needs; they’re the experts, and watching them testing your service is always extremely valuable. But the clinics are invaluable for spreading knowledge of how to design and build accessible services. We’ve always found at least one issue in each accessibility clinic, but we’ve noticed the number of issues uncovered falling as time goes on, which demonstrates the difference the clinics are making. Developers are more aware of accessibility when they’re building features, and are engaging with us to ask about the best way to do things before they start writing code. And every issue we find, fix or prevent is going to make a real difference for our users.
In a world where 1 billion people are affected by inaccessibility, every action we take to improve accessibility really matters. For the work we do in the UK public sector, this is particularly true. An easy, accessible experience helps public servants provide sometimes vital support to those who need it most.
Thursday 21st May is Global Accessibility Awareness Day. On that day we’ll be sharing the top accessibility issues we uncover in our clinics so you can learn from them too.
For more information about Global Accessibility Awareness day, visit globalaccessibilityawarenessday.org
Join us. We’re always on the lookout for like-minded people to join us on our quest to make accessible software that really matters. If you think this is you, then get in touch with us, we’d love to hear from you.
