Advocating for accessibility by design
The first time I came across accessibility was in 2014. I was working as an IT consultant back then and started a new project as a front-end developer. The goal was to rebuild the website of a French Institute. And it had to be accessible based on legal requirements. I had never heard of the term, either during my studies or past work experiences. If you’ve never heard of web accessibility before, no worries! I will share some key concepts below. I will also provide a concrete example on how, as a designer now, I advocate for accessibility and work on building more inclusive user experiences (UX) at ENGIE Digital.
What is web accessibility and why care about it
Web accessibility is a quality of the web built to be usable by anyone, regardless of their situation. You may also find definitions emphasizing that accessible means usable by people with disabilities, quite rightly. In fact, the World Health Organization shared in a tweet that “People with disabilities are among the most marginalized groups in the world”.
And the WebAIM Million, an annual accessibility analysis of the top million home pages, reports that the vast majority of these pages presents accessibility failures. Here are the top 3 accessibility failures and associated examples of potential problems:
- low contrast text: someone with low-vision or colorblindness might not be able to distinguish text over background color;
- missing alternative text for images: someone who is blind and using assistive technologies may not be able to benefit from the information captured in images;
- missing form input labels: someone with a cognitive disability might not understand what is expected as input.
As designers, we strive to create frictionless experiences. This is precisely what accessibility is all about. I think the failures listed above could be solved early on, at the design stage. More inclusive experiences could be built, and product debt prevented by, systematically, for example:
- making sure contrasts are sufficient for texts
- providing a relevant textual alternative for every meaningful image
- defining a relevant label for each input
Accessibility is not limited to these pure interface and experience matters though. Our whole design process can be affected. For example, in user research or tests, it might entail:
- including more people with disabilities in user samples to help broaden our understanding of usability issues;
- updating our interview guides to make sure users are comfortable with sharing feedback on any usability issues;
- making sure users are adequately prompted to share specific settings if needed, and adjusting our prototypes consequently.
I believe empathy is key in our line of work and we should take every opportunity to learn more about people and usage. I think advocating for users is our duty as designers and thus is bringing awareness on (the usual lack of) accessibility.
Infusing accessibility at ENGIE Digital
Accessibility is a subject in progress, here and in most companies probably (think WebAIM Million). And just like in other companies, trained people and oftentimes buy-in at some level(s) are essential to start tackling the frequent product debt associated to accessibility. Lucky for me, I was heard about a year ago!
I have been working since 2019 for eCare. We aim at reducing the carbon footprint thanks to smart home objects. One of our products is called eCare Monitoring. It enables experts to remotely monitor connected installations, like boilers. About a year ago, I tried my luck at pitching accessibility to eCare’s Head. I think having a sponsor is key here to be able to embark the whole team. And that’s what we just did then: first eCare’s Leads and then Monitoring’s team (product, design, development, and QA people).
A kick-off workshop with Monitoring’s team helped pinpoint that being supported by accessibility experts was critical. We did not have enough knowledge or experience on the subject at the time. Over the past months, we have been going iteratively through these stages with the help of an expert:
- Accessibility audit: to identify current issues
- Remediation: to solve identified issues in the short term
- Training: to become more and more independent and progressively integrate accessibility as part of our best practices
You may wonder why the whole team was involved in the process: not just developers or designers. If so, I would ask: what would happen if one person in the team did not work with accessibility in mind? For example, if the Product Owner is not committed, reducing product debt on accessibility may never be prioritized. If accessibility is never tested, we might think our product is accessible to some extent, when it really isn’t. Having every role committed ensures that optimal accessibility is delivered and reduces the risk to amass debt.
I find the work we have been doing as a team to be very valuable. We are improving our product, skills, and processes. For instance, I have been learning a lot on keyboard navigation and how to integrate it to my design process (maybe more on that in a later article…bear with me).
As a team, we can also capitalize on trial-and-errors and share what we have learned with other teams at ENGIE Digital. This is really positive as it brings more awareness and concrete insights to teams that may have doubt on how to approach accessibility.
And you, how do you work on accessibility? Share your thoughts and insights!
