Photo by Daniel Ali on Unsplash

Web accessibility at Mercadona Tech

Intro

If you’re planning on reading this article because you’re hoping to find out about all the good practices on accessibility implemented at Mercadona Tech, then perhaps this isn’t going to be what you’re looking for!

The idea behind this article was born out of the fact that our product (the Mercadona online website) had, and continues to have, a number of web accessibility issues, which on occasion have meant that we’ve been offering a poor, or even inaccessible, experience to people with special requirements.
Unfortunately, poor accessibility support is not uncommon in the world of web development. It is a subject that is neither studied or taught, mainly because it affects people whose needs are, quite often, invisible. If our product is not usable for everyone, it becomes very hard to gather the full spectrum of opinions or feedback on the daily difficulties that may arise when using our web applications.

I’d like to propose a simple but illustrative exercise. Visit a random website and turn off the loading of CSS styles. Would you still be able to use the website without this feature? How would you rate the experience of using it now? How would you feel if this was the experience you had when visiting any website?

Photo by Sigmund on Unsplash

Our failures

We had basic notions of web accessibility and, with the best of intentions, we tried to apply them; however, we found that the results we obtained were actually counterproductive in many cases. Paradoxical though it may seem, most accessibility problems are not solved with large, complex implementations but instead by focusing on the basic tools and elements that are the essence of web development, in particular HTML.

After a initial accessibility analysis we noticed the following basic flaws:

• Incorrect use of the property tabindex=0 in non-interactive elements.
• Implementation of an accessibility loop that impeded access to some elements via the keyboard or screen reader.
• Poorly defined color contrasts.
• Incorrect use of aria properties.
• Incorrect use of divs for buttons or links .
• …

If most of these problems can be solved very quickly, why have we been waiting so long to solve them? Basically because we weren’t able to identify them as problems.

The first step when integrating accessibility in your development team is to learn about and share the experiences of the people to whom these practices are focused.

Our process

In recent weeks we have found ourselves with the need to focus more on accessibility, with the aim of offering a more inclusive product and thus ensuring we fulfil one of the maxims of the Mercadona Tech engineering team:

Technical excellence is not negotiable

Although specific problems are easy to solve, the biggest challenge we faced was integrating into the team’s culture a sense of concern and care for accessibility.

Without this culture, it would be hard going forward to continue creating a fully inclusive product. What we would end up with would be a fairly accessible product, to which we would probably be adding new functionality that did not meet accessibility requirements.

With this idea clear, the first steps we took were focused on sharing knowledge about accessibility throughout the team:

• We educated ourselves on the different types of disabilities, both motor, visual, auditory and cognitive.
• We conducted several mob programming sessions to understand how to use a web page for keyboard and screen reader users.
• And finally, we put what we learned into practice by creating new components of our Design System that met the accessibility requirements of the WCAG as well as following the standards recommended by the W3C.

Next steps

We still have a lot to do; besides dealing with the accessibility problems already identified, there are other key tasks which will need to be worked on if Mercadona’s online store is to become a reference for web accessibility.

• A key idea is that accessibility is not just the responsibility of a single person, or team. Accessibility is something ubiquitous, and any team working on the identification and definition of new features for the product should do so while wearing their accessibility glasses. Only in this way will the product have coherence. If even just one of the parties involved shirks their responsibility, the process will be greatly limited. From the first moment work starts, usually during the research stage, we must keep the full scope of users in mind, this way we can identify improvements, design them in the most inclusive way, and implement them so that they meet all the requirements.
• Collaborating with parties who can help us understand the points of view of those who encounter accessibility problems during their day-to-day lives.
• Although we’re aware that most automated tools for detecting accessibility problems are not 100% effective, using them still allows us to ensure we are meeting the most basic accessibility requirements.
• Continuing to share our experiences and knowledge with the community, allowing us to grow and create tools and services that each day become more accessible.

Conclusion

One of the great discoveries of this process has been the revelation that the key to improving accessibility is to have a firm understanding of the basics of HTML, which has in turn given us a much broader and richer vision of the elements that make up this language, so we can work to apply them consistently in each component of our online store.

On a strictly technical level, the current situation is slightly better than it was a few months ago. We have incorporated accessibility to some components of the web, albeit in a slightly isolated and disjointed way, which itself might not seem like much of a breakthrough. Nevertheless the biggest advance is having incorporated this vision and empathy into the culture of the team. When something is part of your culture, putting it into practice is much easier and faster.