We need to rethink how we build websites for accessibility

Published January 12, 2020
.* :☆゚

Whenever we delve into the world of accessibility or ‘a11y’ in its shortened form in the industry, there comes with it many interpretations, standards, and subjective opinions on the matter. Everyone is affected by it in some way and it is arguably the most important aspect of the website build process. There are many shortcomings to the industry’s current standards however, and I think there needs to be a complete overhaul starting at the browser level if we are as committed to building for accessibility like many of us say we are.

The goal of a11y is to make the digital medium accessible to all humans, regardless of ability. To say that we are for accessibility is a nice sentiment, but it isn’t enough. To build a website for accessibility, you need to understand the perspective of a person who uses high contrast mode or screen readers daily. You need to know the ins and outs of how a website is zoomed in and interacted with, how colours appear and change with high contrast mode, how font anti-aliasing may affect people with vision problems, and you may also need to understand how a website works completely without a mouse. For most developers, thinking in these perspectives is simply incomprehensible and adds to a burgeoning amount of technical knowledge we now need to know. Against time pressure and other technical priorities, this is problem when websites are being constantly churned out and iterated on.

It doesn’t matter how good your intentions are - if you don’t dedicate the majority of your time to understanding screen readers, how they work, and more importantly, how people use these devices, then how can you expect to accurately develop/design a website that can cater for abled and disabled people?

There was quite a large study done last year by WebAIM, and accordingly ‘users with disabilities would expect to encounter detectable errors on 1 in every 13 elements with which they engage.’ Alongside this, ‘97.8% of home pages had detectable WCAG 2 failures!’

There could be many reasons for these failures on our part, but in my opinion, there are two that I feel would probably explain the results the most.

  1. Most developers just don’t understand accessibility enough to make their websites accessible.
  2. Most developers just don’t know how screen readers, voice readers, and high contrast modes differ from normal browsers because ironically, they are inaccessible to most developers that don’t work in a large organisation that can invest in these items.

We have tools to help us, sure. If you google accessibility or look up a11y resources on Twitter, there are a tonne of links and articles available. There are pattern libraries, best practices, WCAG, aXe, and lighthouse by Google themselves. And still, most websites will likely have some sort of accessibility error despite the multitudes of information and tools available to us.

Unless you are a developer specialising in accessibility (meaning primarily working on accessibility using tools for disabled people on a constant basis), building a website with a11y in mind is only going to get you so far. There are standards with quantifiable numbers, such as those with colour contrasts or having certain landmarks in a certain order, but there are also many ways of being “right”, in particular, when using ARIA attributes. However, if you are wrong with regards to a11y, you are most definitely wrong and there is no two ways about it.

Unfortunately, there is no often no way of knowing you’ve done something wrong, because many developers simply lack the necessary resources and perspectives to test and modify their code accordingly. Because of this, the time it takes to make a website accessible can balloon drastically. This is when a11y becomes less of a priority, and when you have to justify more and more time to make it accessible to disabled people.

Examples

You may have heard an image needs an alt tag so disabled people can get a description of the image being displayed. However, if it is just decorative, it is better to give it an empty alt tag rather than no alt tag at all. Sure, this is easily done, but is it a good solution? Personally, I feel like this is such a clunky way to improve accessibility and a better solution would be the browser just skipping over images without alt tags by default without needing further effort from the developer.

Then there is slick slider, which is in my opinion one of the best and most flexible carousel scripts out there. The script has many accessibility issues however, due partly to the fact that attributes are added and changed in an improper way. These attributes weren’t added in for fun, they were in fact added to improve accessibility. However, since the attributes were used wrongly, it in turn degrades the overall accessibility of the script.

This is just one example of many that showcases how improper use of a11y enhancements can negatively affect the outcome of a website. It’s not that developers don’t care about accessibility. The problem is there is too much disconnect between the developer and the problem at hand. Adding extra attributes won’t magically fix the problem of making a website accessible.

Lastly, there is simply the fact that everyone’s perspective is different. You can simulate colour blindness and vision problems, but abled developers will never understand what that is like on a daily basis, and so either they won’t prioritise this as much, or they won’t know the best solution to the problem.

There is simply no possible way a developer can understand and cater to the needs of every abled and disabled person. No matter how much of an a11y expert you are, you can memorise the attributes and know all the landmarks. I can guarantee if you’re an abled developer, you will most likely still make mistakes when building for accessibility, because the current standards are oftentimes very confusing, contradictory, and vastly different across many different articles and handbooks.

If you are freelance and don’t have access to a screen reader, a newbie that just wants to get things working, a developer that doesn’t have time allocated to testing for keyboard access, or you’re just ignorant to the extra accessibility features in the settings or browser - these are all issues we face when building a website for accessibility.

So what can be done about this?

As you may have surmised, I want to see an overhaul of accessibility practices from the ground up. From the browser level, where major companies such as Google, Apple, and Mozilla actively engages with the screen readers and accessibility tools on the market and incorporates standards from these devices into browsers by default.

We need html elements that are by default accessible. Things such as images, buttons, menus/sub menus, and multi select combo boxes would be a very welcome addition that would also cut down on the errors and extra code and attributes we need to remember. Right now, many of us are just set up to fail, because the way accessibility is tackled with these elements are often clunky and misinformed.

On a consortium level, I feel like WAI and W3C needs to do better. WAY better. Not only are their websites a clunky mess for abled and disabled people, the WAI website isn’t even completely navigable by keyboard. Speaking of which, have you ever tried navigating a website’s main menu by keyboard? It’s often always a mess and most developers don’t spend enough time testing or ensuring each link is focusable, especially if it a is a huge mega menu. This is a huge opportunity for standardising menu accessibility across all browsers, and ease an aspect from the development process that is currently so murky and time consuming.

Lastly, we need more insight from disabled humans, and we need to hire more disabled developers that can share their insight and perspective. Major browsers should be at the front line for this- it’s really the only way forward I can see in improving the state of a11y across all websites and web apps.