How to Introduce Accessibility into a Team That Has Never Thought About It
It’s no surprise that accessibility is something that gets overlooked in many teams; it’s like that old doll you leave tucked away and forgotten in the cupboard. Every time I join a new company and discover, to no one’s surprise, that it hasn’t been taken into account, I know exactly what lies ahead: it’s time to roll up my sleeves and brace myself for a long battle. Just like when you fought to introduce testing to your team. Or when you wanted to introduce DevOps.
Because the reality is that accessibility rarely features as a priority. In fact, every time I bring up the subject, people tend to roll their eyes and then tell me the typical line: “People with disabilities don’t use our product” or “We’re a small company and we don’t have time for that."
Accessibility is often ignored because most people who develop digital products believe it doesn’t affect them and, above all, that they wouldn’t benefit from creating more accessible products. If they can generally complete the workflow without any problems, the majority of the population will be able to. And if two or three can’t, what does it matter? That won’t affect the bottom line either.
So the first thing I have to do when I join a team… is to fight against my colleagues’ prejudices.
The Ethical Side: When You Leave People Out
Failing to consider accessibility means excluding a significant proportion of the population, closing the doors to a world of possibilities for many people with various types of disabilities. It means condemning them to an unfair world they will never understand.
Sometimes we talk about accessibility as if it were an optional improvement or a sort of ‘nice to have’ that is added when there is time. But in reality, we are talking about millions of people who are left out.
So yes, the ethical aspect matters.
It matters to understand that when we build digital products, we are also making decisions about who can use them and who cannot.
When the Ethical Argument Isn’t Enough
However, I have learned that assuming people will devote their time and resources out of the goodness of their hearts does not always work. There are situations where we have to talk about money to make them take ethics seriously.
So let’s talk about the figures.
According to the WHO, 1 in 6 people has some form of disability; as the population ages, more and more people have some form of sensory, motor or cognitive disability. Furthermore, between 15 and 20% of the population has some form of neurodiversity, 4% suffer from anxiety, and almost 6% from depression.
Now that we’re looking at the figures, all those percentages actually represent people who would benefit from accessibility and who are currently being left out. So, I’m sorry, but yes, you’re probably losing money right now by not making your products accessible.
Accessibility also has an impact on business.
Accessibility Can’t Live Only in Frontend
One of the most common misconceptions is to think that accessibility is “the front-end team’s responsibility." As if you could completely separate that department and leave it isolated from everything else, floating in a vacuum.
But the reality is quite different. Accessibility must extend beyond the front-end developers; it must be part of the company’s culture. Everyone must understand its value and take their share of the responsibility.
To begin with, the design team must understand accessibility in order to create interfaces with sufficient contrast ratios, typefaces that are friendly to people with dyslexia and create easy-to-understand flows with text that is explanatory enough yet simple enough so that no one gets lost.
On the other hand, Product Managers need to understand the value of accessibility and start incorporating accessibility requirements into user stories. It is not enough simply to define functionalities; they must also define how different types of people will be able to use them.
Others who are often overlooked are staff from other technical departments. It is useful for those working on the platform, backend or help desk to also understand the value, as there will be times when they have to make technical decisions that may affect overall accessibility.
We must also bear in mind those at the top, the managers, as they will need to allocate time and resources to implement all these changes, so they may be among the first who need to understand the value of doing this work. If accessibility is never given a place, it will never happen.
It should even start to be valued in recruitment processes. Not everyone needs to be an accessibility specialist, but there does need to be a certain awareness of it, and the person should at least be willing to learn about the subject.
When only one person is concerned about this, the system ends up failing as soon as that person leaves.
Before Fixing Things, You Need to Understand the Problem
Once we have secured the necessary support within the organisation, we need to move on to the next step: creating a realistic plan. To do this, we must carry out an in-depth analysis of our product’s current situation.
To understand where we stand, we must combine the use of automated tools to review our code with manually testing workflows using different assistive technologies, involving people with various types of disabilities or circumstances.
As the product we’ve developed is likely already quite extensive, the most sensible approach is to create a roadmap that progresses from simpler to more complex tasks and is implemented gradually.
In this regard, it is advisable to start with so-called ‘quick wins’: small changes that involve little technical risk but already represent an improvement, such as using semantic HTML or correctly reorganising headings…
Once these initial improvements have been addressed, the more complex issues will arise: making modal windows accessible and correctly managing focus. In these cases, it will be important for the team to remain patient, as they may require reworking large components, adjusting architectures, or even modifying aspects of the design.
If we try to make all the changes at once and too quickly, the result may not be what we intended, and we may even end up alienating the very people involved, particularly those in design and development, as they may become overwhelmed by all the redesign work and ARIA attributes.
Similarly, it is important that the roadmap includes identifying the priorities, the order of those priorities, the goal we are working towards, and what will and will not be covered.
Training Completely Changes Perspective
As part of this roadmap, we mustn’t forget that one of the first things we need to do is provide training for everyone on the basics, so that accessibility permeates the organisation, and more specific training for those in design and development.
And by training, I don’t just mean reading the WCAG, we love this guide in the accessibility world, but sometimes it’s not what we need. I also mean understanding what assistive technologies are, the different types available, how keyboard navigation works, the different types of neurodiversity…
That moment is often transformative. When some people put themselves in others’ shoes and experience for the first time the discomfort of navigating an interface that wasn’t designed for them, it’s usually a very special moment.
Accessibility Must Be Part of the Definition of Done
Another step we need to incorporate is ensuring that accessibility is taken into account as part of the development process. Not as something done as an isolated task after the fact, but as something that must be carried out during the actual implementation of the tasks. As part of the Definition of Done.
Just as we must add tests to ensure that things work as they should, and that we do not break them later on, it is important in our code reviews that we ensure compliance with certain minimum accessibility standards before considering a task complete.
At this point, we must decide something very important: what our standard will be. Whether we are going to follow WCAG A, AA or AAA, which criteria we are going to prioritise, which assistive technologies we are going to take into account…
We should also take the opportunity to create an internal accessibility statement. Not just as a corporate document, but as a practical reference for the team. A place where it is clear what principles we follow, what tools we use and how we validate the work.
Automate So You Don’t Depend on Memory
These days we have to keep a thousand things in mind, which is why it’s important to automate certain tasks.
We can configure certain linters to remind us to make specific changes or introduce automatic validations in CI. For example, a GitHub Action that runs accessibility checks and blocks a pull request if it detects certain issues.
The aim of this is not to punish anyone but to avoid relying on a good memory.
Accessibility Is Quality
Accessibility shouldn’t depend on having ‘that annoying person who’s into accessibility’ on the team constantly nagging us; it should be an integral part of the way we build our products.
Just as we now take testing and security for granted, accessibility should stop being seen as an afterthought and start being seen for what it really is: quality.
Because ultimately, building accessible products isn’t about complying with regulations; it’s about deciding that people matter.
Fuentes:
who.int/health-topics/disability
https://thendalliance.org/what-is-neurodiversity
https://www.who.int/news-room/fact-sheets/detail/depression
https://www.who.int/news-room/fact-sheets/detail/anxiety-disorders
Want to know a little more about who wrote this article? 👇
Front-end developer specialising in accessibility. I’m a restless soul who likes to get stuck into a bit of a mess. I’m a mentor at step4ward, I write articles and give talks. A geek and restless by nature, away from the keyboard I enjoy cinema, board games and being a dungeon master