I try my best to find out how to improve processes that lead to accessible digital products. Learning from others is the key of improvement and can save a lot of time and also money, so following up on articles, webinars, conferences can be worth it. It’s really logical – get the larger overview, filter out potential sales pitches and learn from mistakes others have done can give you real knowledge. But it’s only a start. You have to have a plan first and to have a plan it’s wise to know what to do and how to do it.
Design is often a part of the plan. In a perfect world the developer would also be a designer. I really mean it. Or the other way around – the designer would also be a developer. Implementing aesthetic, semantic, usable and accessible products with effective, semantic, secure and performant code.
Implementing aesthetic, semantic, usable and accessible products with effective, semantic, secure and performant code.
Designer and developer, maybe we could say full-stack designer, or as in the early times – webmaster?
Full-stack designers – the rise of the webmaster
Early days of internet had so called webmasters that could do everything – from design to front-end and back-end code. We are currently more and more specialized as the field grows in so many directions and both design and coding are getting more complex. So usually we have to have a team of specialists. At least a designer and developer. But with new revolution of so called no-code or low- code solutions we are again getting closer to the “webmasters” – people that can take the project and click whole sites together with modern “What You See Is What You Get” (WYSIWYG) tools. They make it quite easy to also implement more and more integrations, from accepting payments to full-blown e-commerce or even Customer Relationship Management (CRM), all centralized and possible within single interface.
This solutions had quite poor reputation before but it seems that they are getting more and more users and also better support for accessibility. And this is huge, because the more they will be used the larger their impact on the web is. Personally I was more a fan of make it yourself but I can definitely see the motivation and shorter time-to-market agendas. We could make an online product in some months or even weeks with such tools, just to test if it is viable and then if needed make some improvements or custom solutions while already on the market.
Designer’s responsibility for accessibility
No- or low-code or just the wireframes alone – designers have a huge responsibility for overall accessibility of the product. I will not go through the whole WCAG and map the success criteria that should be a part of a good design in this post but according to studies the majority of accessibility problems can originate in design. Long before development potentially do the situation even worse.
Designers should invest more into full understanding of their impact on accessibility. Incorporating disabilities when defining personas, making wireframes accessible and complementing them with accessibility notes like focus flow and keyboard interactivity, doing user testing with people with disabilities, knowing the best practices around semantics, possibilities and limitations of native HTML, understanding the possibilities that can be achieved with ARIA – so to round it up – it goes far beyond typography and color contrasts.
Designers should not expect developers making choices that they should define for them in the first place. Dialog with developers can for sure help to make more effective decisions in the design where we must deal with code problems, but designing for interaction should not be passed on to developers. Not without proper conversations and guidelines, ideally within design.
Designers should also understand how some end users use the internet (or apps) in a totally different way. How does a screen-reader user use the product? And how does a speech controlled assistive technology do it? What about switch devices that some users have to use?
There is a lot to know and a lot to think about when we really want to make our products accessible. But it is doable and it only takes awareness, empathy, cooperation and knowledge.
WCAG is the minimum
I’ve written about it a lot but it’s so important that I have to write it again. WCAG is the minimum, at least WCAG 2.1 on level AA. So I really do not understand people that can not even make it to there. The guidelines are maybe a bit too wide and people that first read them look for recipes not only directions. Their openness may be a problem for some that are missing experience. I get it. I really hope that WCAG version 3 will fix that. It is too soon to know but I am an optimist.
But some of the success criteria from current WCAG on level AA are extremely simple and yet we manage to go against them. I will not say that only designers do this as it is evident that developers should also do more for the accessibility. I’ve written on automatic testing for accessibility quite a lot – and won’t go into the details again – but it does really well for code-based problems. And sometimes also contrast, when code is the reason at least. But automatic testing does a poor job on other aspects of the accessibility, especially design and content oriented. Maybe that is also the reason behind thinking that accessibility problems should be fixed by developers as we can only detect problems that reside in the code with automatic tools. Can be the case, I can only speculate on it. But the fact is that both designers and developers should invest more time into really knowing WCAG and how to implement it. The same goes also for content providers, writers, editors – they should also do their part as it can also be the crucial one; what does it help if designer and developer make a perfectly accessible site and then the content that is added or changed breaks some parts of accessibility?
When we add or change features they must be accessible, when we add or edit the content it must also be accessible. And so on. It is a team sport and it is never-ending journey.
