How designers and developers can work together to fix accessibility issues

How designers and developers can work together to fix accessibility issues

Jan Boeckx

•

10 January 2025

Accessibility

Celebrating the birth of the European Accessibility Act and the collaboration between Humix and Sirius Legal on this topic

Imagine if accessibility issues simply never existed in your digital product. No bug fixes. No post-launch patches. Just a perfectly inclusive experience from the get-go. Sounds dreamy, right? It’s not just wishful thinking—it’s achievable when designers and developers work hand-in-hand, making thoughtful, user-first design choices. Yet, many teams still fall short, neglecting to consider the needs of all users upfront.

The increasing impact of accessibility

Accessibility is making waves across the digital world. From rising market demands to climbing search volumes on Google, it’s clear that accessibility is becoming a priority for businesses. Plus, with new European Accessibility Act mandating that all new digital products be accessible by 2025, accessibility is no longer optional—it’s a necessity. To build and shape those digital products, UX designers and developers get involved. How well they collaborate can determine whether accessibility issues are prevented or inadvertently created.

💡 Did you know… We hosted a webinar that included both legal and practical implications of the European Accessibility Act? Highly recommended for those who want to dive deeper and understand what the legislation means for your website.

To the webinar

Why do accessibility issues arise?

The recent push for accessibility is not just about compliance; it’s about (re)building digital products that are inclusive to any user. As domain experts, we often notice accessibility issues get pointed out. Issues that could be avoided entirely with better collaboration between designers and developers. In fact, 67% of accessibility issues can be traced back to design decisions. That’s a staggering figure—one that highlights how critical it is to make accessibility part of the design process from the very beginning.

💡 Did you know… We hosted a webinar that included both legal and practical implications of the European Accessibility Act? Highly recommended for those who want to dive deeper and understand what the legislation means for your website.

To the webinar

Why do accessibility issues arise?

The recent push for accessibility is not just about compliance; it’s about (re)building digital products that are inclusive to any user. As domain experts, we often notice accessibility issues get pointed out. Issues that could be avoided entirely with better collaboration between designers and developers. In fact, 67% of accessibility issues can be traced back to design decisions. That’s a staggering figure—one that highlights how critical it is to make accessibility part of the design process from the very beginning.

Source: Deque.com

The blame game: designers vs. developers

Who’s to blame for accessibility issues—designers or developers? The truth is, accessibility is not just a one team game. Its guidelines and criteria are often divided between different teams and different roles. Therefore, teams are required to collaborate in order to solve the occurring issues. Splitting these accessibility problems between different teams often isn’t beneficial at all.

The root of almost any accessibility issue is misunderstanding your actual user.

On the one hand there’s designers. They usually love freedom and creative control. This often results in custom components. Components that need to be build by developers. But custom components come with a catch: they often leave developers guessing about expected behaviour, and accessibility characteristics frequently get overlooked.

Ever heard of elements like Name, Role, and Status? They might seem minor, but they’re crucial for creating accessible and robust components.

Take a “custom” pop-up that’s mistakenly configured:

  1. Name: /

  2. Role: image

  3. Status: /

Using an image as a pop-up means that assistive technologies won’t recognize it as a pop-up at all. Instead, users relying on these technologies will perceive it as an unnamed image—missing the intended functionality entirely.

Source: Deque.com

The blame game: designers vs. developers

Who’s to blame for accessibility issues—designers or developers? The truth is, accessibility is not just a one team game. Its guidelines and criteria are often divided between different teams and different roles. Therefore, teams are required to collaborate in order to solve the occurring issues. Splitting these accessibility problems between different teams often isn’t beneficial at all.

The root of almost any accessibility issue is misunderstanding your actual user.

On the one hand there’s designers. They usually love freedom and creative control. This often results in custom components. Components that need to be build by developers. But custom components come with a catch: they often leave developers guessing about expected behaviour, and accessibility characteristics frequently get overlooked.

Ever heard of elements like Name, Role, and Status? They might seem minor, but they’re crucial for creating accessible and robust components.

Take a “custom” pop-up that’s mistakenly configured:

  1. Name: /

  2. Role: image

  3. Status: /

Using an image as a pop-up means that assistive technologies won’t recognize it as a pop-up at all. Instead, users relying on these technologies will perceive it as an unnamed image—missing the intended functionality entirely.

Moving from fixing problems to preventing them

So, how can we make accessibility something that doesn’t need “fixing”? It starts with genuine collaboration between designers and developers, involving both roles at every step of the process. Accessibility is a shared responsibility. By building accessibility right into our design systems and workflows, we can make sure our digital products are inclusive from the start.

Takeaways

  1. Improved accessibility starts with improving your designs

  2. Avoid custom components, but foresee explicit accessibility guidance if used

  3. Shared knowledge and collaboration prevents accessibility issues

Do you have any questions?

Get in touch! Feel free to contact Jan for more info regarding the article.

Moving from fixing problems to preventing them

So, how can we make accessibility something that doesn’t need “fixing”? It starts with genuine collaboration between designers and developers, involving both roles at every step of the process. Accessibility is a shared responsibility. By building accessibility right into our design systems and workflows, we can make sure our digital products are inclusive from the start.

Takeaways

  1. Improved accessibility starts with improving your designs

  2. Avoid custom components, but foresee explicit accessibility guidance if used

  3. Shared knowledge and collaboration prevents accessibility issues

Do you have any questions?

Get in touch! Feel free to contact Jan for more info regarding the article.

Some of our other blogs

User Experience

Auto Layout in Figma: everything, everywhere, by everyone involved, all the time

User Experience

Enshittification: the slow decay of online products and how to avoid it