Well, not quite…
The audit of a healthcare provider for visually impaired people did not turn out well for us: ‘No, your product is not accessible for our population.’ Ouch. Why did we need this reality check? And what does the road to becoming more accessible look like for us since then?
Accessibility means that your product can be used by everyone. That includes anyone with a motor impairment, blind or visually impaired people, those with colour blindness, deafness or a cognitive disability too. Because if you’re a wheelchair user and you need to go to the 2nd floor of a building, there needs to be a lift to enable you to do that – the same goes for the digital world. Accessibility means that everyone – with or without a disability – has the opportunity to benefit from all forms of digital information and services. And that includes our ehealth platform.
Why wasn’t our platform accessible enough? Not out of unwillingness, but more because of a blind spot.
There is an infamous ‘blind spot’ example from Apple. The company launched a health app in 2014 and claimed that it would let you monitor all the metrics you would be most interested in. You could measure everything from your heart rate, blood alcohol levels, and even your daily chromium intake. Everything. Except for the menstrual cycle. That’s something that male-dominated Apple hadn’t thought of.
Sounds stupid, right? But it’s equally strange that we hadn’t previously tested whether blind people were able to use our platform. Or whether the red and green buttons used to start and end a video call were clear to people with colour blindness. Or if the contents of audio fragments were available in a different format when a user is deaf or hard of hearing. Strange we hadn’t tested those, but unfortunately true.
The reason is most likely because we don’t have these experiences ourselves. It simply didn’t occur to us to test for things that we didn’t expect to be a limitation. You don’t know what you don’t know – until that audit. But, after falling down, it’s time to pick yourself back up.
Testing, testing, and then testing some more
We started by increasing our knowledge. We studied the WCAG and WAI-ARIA standards – the guidelines for digital accessibility – and compared our product against them. And of course, we started testing: we asked people who experience digital limitations to show us how they use our platform.
In summer 2020, several people from Visio, centre of expertise for visually impaired and blind people, tested our ehealth platform. “During those tests, I saw users struggle with certain parts of our software,” says Minddistrict front-end developer Richard. “That was a great motivator for me. Something might make sense on the technical side, but that doesn’t automatically mean the software has good usability.”
The team describes the problems the testers ran into: buttons that were inaccessible with the tab key and therefore could not be read out or clicked. Images without a description, meaning the user couldn’t know where there was an image and/or what it represented. Layered menus that were difficult or even impossible to navigate without a mouse.
The testers were not surprised: “Websites often have pop-ups whose content cannot be read. The screen reader just reads around them – it’s blind to them, too.” Pages must have a clear structure, because users memorise that structure and use it to navigate. Links should have very clear labels. And images should have a description: “Unreadable, says the screen reader about where I am now on the screen. I think it’s an image – I come across this a lot online.”
Minddistrict has learned a lot in the last year. We’re now testing and experimenting a lot more ourselves. We use a contrast checker for colour contrasts, try tab navigation and various screen readers, like VoiceOver. It’s often frustrating, but very useful.
Our processes and collaboration between teams have also been adapted to incorporate the accessibility aspect. Front-end developers work together with designers and quality assurance on the design, development and testing of UI (user interface) components on accessibility. The library we created contains items that can be better used and combined to create an accessible interface.
We are now tackling a different part or functionality of our platform each time to improve accessibility. Little by little, we are getting closer. “We are not there yet, but we’ve made the culture change,” says designer Ewoud. “That we’re aware of problems that we do not encounter ourselves.”
Prepared to fail
We will probably get a few more things wrong along the way before our product is truly digitally accessible. But that’s okay: we need the direct input from different perspectives and different audiences. We need to be confronted with our assumptions or prejudices. The more often we are corrected, the better our product will become. On to accessibility!
Want to contribute to accessibility yourself?
Do you have a comment, or want to correct us on something? Let us know!
If you’d like to contribute to making the Minddistrict platform accessible, see our page on Working at Minddistrict.
This content was originally published here.