Studies show that 67% of accessibility issues originate in design (opens in new window).
When we think about it – it’s not so strange – design is the blueprint, the plan, the wanted result.
So, when plan doesn’t include people with disabilities it’s only logical that the end result can’t include them either. And that we get a gap between design and end result (I am referring mostly to webpages in this post, but thesis is valid for any product).
When I use the word design I don’t think only about the visual design but also the user experience design.
Design is more than how things look, it’s also how things work.
famous quote from Steve Jobs (and he probably borrowed it from other people as well).
The same can needs to be applied to digital products as well – when we design them we need to think how they will work, we need to think beyond visuals like color, visual hierarchy, visual hints about functionality, responsive design and so on.
We need to think about people with disabilities, how will they use the product and that’s why they need to be represented in the personas, when we use personas. That’s why we need to annotate visual design with the mechanics behind it.
Furthermore we also need to think about different ways of how the interface can be used – not only mouse and touch, but also keyboard, voice control, screen readers, refreshing braille screens, switches, sip and puff devices and so on. Basically we need to understand the user, right? And as there is no average user (opens in new window), we need to consider the “extreme users” when we want to include widest range of people.
Gaps in knowledge and understanding requires learning
So, yes, I am basically saying that designers need to learn about these things. I know that some of the things can get very technical very quickly, but when we design for a platform we also need to know the platform. And web, as a platform is at the minimum HTML.
I am not saying designers need to code, although that would be optimal (at least on the prototype level).
When we design for a platform we also need to know the platform.
my reflection about how designers need to understand the web as a platform.
I am thinking more about that they need to know about possibilities and limitations of the web as a platform. If we know what is possible with building blocks of the platform – starting with HTML (and also what isn’t) we can make our website more accessible from the start. Even HTML is not perfect, but using it instead of making new things up, makes our products better.
As we know that HTML is quite limited when it comes to advanced interactions and components needed for more interactive web applications, it is obvious that designers also need to know basics of ARIA (Accessible Rich Internet Applications, opens in new window). ARIA extends HTML, especially for screen-readers and other assistive technologies, and adds additional possibilities that can’t be achieved with only HTML, so if we are designing for the platform that is limited to HTML and ARIA we should know what are the possibilities they offer.
That way we can lead the developers and make our product (more) accessible. As design is leading with defining the visuals it should also lead with defining the behavior. And with behavior I also mean non-visual behavior, like what is announced to screen-readers, for example.
And there we also get to the idea that designers should also understand basics of assistive technologies. Again, not be proficient in all the advanced possibilities they offer, but the basics would come a very long way. Understanding mouse and touch alone is not enough if we want to make our products accessible. Designers need to also understand how keyboard, zoom, screen-reader and voice control are working, at least.
So that it is not the developer that designs the experience for those alone. Designers need to design the experiences for all users.
Designers need to design the experiences for all users, including users with disabilities, so they need to know basics about assistive technologies to design for all.
reflection that besides knowing the platform, designers need to know the assistive technologies as well.
Practically we come to a process. At the start it can be checklist based, before it is natural. And working in isolation potentially brings a lot of trouble as well. If design and development are working in isolation with some short briefs, quick annotations and meetings we have another gap – the gap between design and code.
Gaps between design and code
We need the design to be converted to code. And if we want the product to be accessible developer needs to interpret the design with accessibility in mind. If both designer and developer fail to understand and implement accessibility it’s obvious that final product will not be accessible.
And if designers don’t define how things will work for users with assistive technologies then, chances are, developer will not make the needed code. It can happen that developer is aware of the missing parts and make own assumptions and implement them, but then we risk that design didn’t want it to work like that. And it’s obviously not the developers responsibility to define design.
An example: if designer makes a custom component and only defines how it will be used with mouse and touch, then the developer needs to design the experience for keyboard and other assistive technologies. If developers have the awareness and knowledge about accessibility that is. Often such experience is forgotten and end product is very likely inaccessible for groups of users.
So even if developers really have the knowledge and understanding it is not enough. Them alone can’t really design the overall experience and need to at least check their decisions with the designer. If designer even understands what they mean. Again, I am not only talking about visual designers but user experience designers. It is, at the end, the user experience that needs to be designed, not only the visual one.
Closing the gaps means having the culture, knowledge and cooperation
Designers empowered with knowledge about HTML, ARIA and assistive technologies (basics, and the ability to read the documentation goes a long way) that define the invisible user experience and lead the developers when they convert designs to code are needed to close the gap between design and code.
On the other side of the gap we also have the developers that need to have better understanding about details in HTML and ARIA (especially what is supported, what are best practices for implementation and support in assistive technologies), but they also need to be able to use assistive technologies to a level that makes them proficient in testing their own work before it is released. Shifting left requires this, otherwise we are again at risk that testing in the end (or end users) find inaccessible parts in the user journey.
As we can probably understand this kind of knowledge and experience needs a shift in culture actually. Both designers and developers need to be trained and not just left alone searching on the internet, or even worse – outsourcing problems to Large Language Models to help them.
There are thousands of blog posts out there with different information, sometimes even incorrect or just outdated, free official sources beyond standards themselves are often limited, stuck at basics or outdated as well, and training often needs time and money dedication that is sometimes difficult to get in the middle of the project with tough deadlines.
Therefore leadership is crucial, as always and closing the gaps can’t be done without investments on all levels. Even when official education will include accessibility for all roles (this is still largely a work in process even if WCAG 1.0 was published in 1999), we will still need to build our cultures, train people and implement accessibility in all vital processes to make our products (more) accessible.