I stumbled upon a post from Mark Steadman called “Is Accessibility Difficult for Developers” (opens in new window) and decided to write some thoughts of mine on the why (because I think that the answer for most of developers is that accessibility is difficult).
Lack of awareness and understanding
Times change and I must say that awareness and understanding about why we need to make things accessible is way better than it was. With help from mass media covering Web Accessibility Directive and similar legislation in other parts of the world I am quite sure people are more aware about it. But it’s still a long way for accessibility top be mainstream. Most experts I’ve talked with say that universities should do more about it and I agree. I’ve talked to some people fresh out of universities and some of them still didn’t learn about it on their university. I also see that self-learned developers may miss the whole subject if they learn from teachers that don’t teach accessibility or maybe even teach it the wrong way (I will not name names but I’ve seen some courses mentioning accessibility overlays as a solution, probably sponsored by the vendors).
After we get awareness we also need to understand what accessibility is all about and what it isn’t about. I understand that reading WCAG is time consuming when you have a deadline and potentially also an imposter syndrome because of all the new things you have to learn before you can deliver. Adding more stuff to know isn’t helpful at all. And reading WCAG does not really help a lot when we must understand it. The only viable solution is to invest time and learn about the practical aspects of accessibility. All roles need it, designers, developers, content creators, project managers. Accessibility is a team effort, so the team has to learn about their own responsibilities.
Thinking accessibility is only a compliance problem
Even with some awareness and understanding we may think about accessibility as a compliance problem. This may be so because of still not enough awareness and understanding, but it may also be because of our customers or even managers. We should know that accessibility is the right thing, both ethically and for business. And if we really agree with the social model of disabilities then we know – making our product inaccessible makes people disabled.
Accessibility is not only a compliance problem. It has become a compliance problem because it was ignored so long by so many. If we would all make our products accessible it probably wouldn’t be a compliance matter at all. Maybe in the future we will have to make our digital products more environmentally friendly and maybe it will also be a compliance problem if we will fail to do so. I think that if we were making our best efforts about it now it is less of a risk to have it as a compliance in the future. And the same goes for accessibility – if we were making things accessible from the start it would be a natural part of our digital products and maybe never a compliance problem.
Making things accessible is the right thing to do, both for people and for businesses. It’s the right thing to do for our end users and for our clients or stakeholders. Compliance is just there because accessibility is still neglected by many, much too many.
Accessibility is difficult because WCAG is difficult
WCAG in it’s current form is not the most accessible document, I agree. At least not for people used of developer documentation with practical examples they can copy paste and they “just work”. And it’s format is not friendly for designers neither. Too little visual examples and too much text with sometimes cryptic words that need translation.
If we want to first understand why is WCAG written in such a way we must check the process and people behind it. And maybe even more importantly – their goal. Making a standard that can be applied to “any” digital technology out there is no easy task. It’s no wonder it’s so long, I might add. If we think about all the progress in technology we can immediately see that WCAG is actually extremely short. And trying to be agnostic and somewhat future proof isn’t easy either.
I loved the blog post from Karl Groves called Is WCAG 2.0 too complicated? (opens in new window) where he explains it brilliantly. The key concept from that post for me is “accessibility isn’t hard when you learn to consider accessibility along the way”. Please read the post and I am sure it will make some parts more understandable.
I don’t know any blind persons that can help me
I’ve actually heard this from a person once – I don’t know any blind person that can help me – when I asked what is stopping them to make things accessible. There are multiple problems with this kind of thinking and I tried to explain that to them;
- Accessibility is not only for blind persons, it’s for people with different disabilities, people with combinations of disabilities and actually even for you and me.
- It’s best practice to check your products work for people with disabilities, but first you have to do all you can by yourself, otherwise you can just waste everybody time and money.
- It’s not so hard to learn to use the basics of a screen-reader and how to write accessible code in the first place.
I just need to code what they designed
Often developers just don’t get any/enough information about accessibility from designs. So they have to think about semantics and accessibility by themselves. Or worse – they don’t think about semantics and accessibility at all. As mentioned before – accessibility is a team effort. When we are forced to work in “silos”, like for example design agency sending design to developer with no discussions about accessibility, we end up with poor or no accessibility.
Some parts of accessibility originate in design and when developers just have to “code the design” it may be hard or even impossible if they don’t have all the information. Sometimes designers use advanced patterns/widgets that need to respect a lot of different criteria that isn’t defined and therefore not implemented. A very basic example is a custom made drop-down (or select if you want) where we need to think about a lot of details if we make it from scratch.
Cooperation and common responsibility with communication is the only way here. Leaving all of accessibility to developers is one of the largest mistakes I’ve seen out there. Delivering digital products needs to support different accessibility requirements and we need to plan for it in advance. Keyboard usage, zoom, screen-reader support and so on doesn’t just happen when we don’t plan it in advance.
Trusting false statements about accessibility of third parties
Designers and developers are now just a “one line install” away from widgets, whole design systems with literally thousands of components, and even full-blown applications. This is of course perfect for some cases but when we use such third party code we are responsible to check if it will not represent a barrier for our users. We must check if it really is accessible before using it. It is not enough to trust some paragraphs that producers made where they just say “it’s accessible”.
What kind of testing did they do? Are they documented? Which assistive technology was used? Any open accessibility bugs? Those are some basic questions we need to get answered. Otherwise we need to invest the time and test it before we use it.
We’ll just use more ARIA
WAI-ARIA must be used with caution, otherwise we can even make our products less accessible. Just adding ARIA will definitely make things worse. For the first not all of it is actually supported and for the second there are rules we need to obey.
WebAIM Million project (opens in new window) measured use of ARIA for multiple years and it has increased 26% between 2021 and 2022. Yet the overall accessibility of webpages is still almost the same. And they even found out that home pages with ARIA present averaged 70% more detected errors than those without ARIA. This isn’t an indication that ARIA caused the problems but it is an indication that pages are getting more complex.
Always remember the first rule of ARIA (opens in new window) – use native HTML element before reaching out to ARIA, whenever you can.
Conclusion
I am learning about accessibility each and every day. And I would like to again warn that when we are talking about making products accessible we need to talk about two different things: normal websites (more or less static documents) and web applications. I don’t really see any issues in making normal websites accessible. It’s not hard. It just take some planning. Making web applications accessible is way harder. Doable, but harder. So yes, accessibility can be difficult, but it really depends what we have to build.
When we invent new interactions we need more time to test and verify we can do it accessible. So whenever we need to invent, please consider Jakob’s law (opens in new window): “users prefer your site to work the same way as all the other sites they already know”. I would even go so far to say that the same can be applied on component level – “users prefer your components to work the same way as same components on other sites work”.
Making WCAG itself more accessible is obviously also an accessibility issue that needs to be fixed. And with W3C Accessibility Guidelines (WCAG 3, also called Silver) it seems that will also be fixed. As many others wrote – it’s time to be proactive now, so that we will produce a more accessible accessibility. Best way to be proactive with WCAG 3 is to follow up on WCAG3 (Silver) GitHub issues (opens in new window) and try to be constructive.
