The Most Common Failures Which Negatively Affect Accessibility on Your Website
Recently, I’ve encountered an evaluation of website accessibility which was conducted in February 2020 by Webaim. According to the results, the most common types of failures are:
- 86.3% of pages had low contrast text.
- 66.0% had missing alternative text
- 59.9% had empty links.
- 53.8% had missing form input labels.
- 28.7% had empty buttons.
- 28.0% were missing document language.
Why have I decided to write about this topic? Because I’ve been getting an impression that the topic of accessibility has recently become quite popular. On social media, almost every week, I can find webinars, workshops, or other events dedicated to the area of accessibility. There are many forums and groups where specialists, juniors and disabled people share their experience and help one another. I follow a lot of people who do their best to spread awareness about accessibility. But even after that, I still see really bad results from Webaim evaluation and I wonder how long it’ll take to receive a report where we can find out that at least 50% of the evaluated websites meet the WCAG 2.1 requirements.
I hope that this year’s report turns out to be better!
Accessibility is so important to me. I think that sometimes I have exaggerated expectations when I explore new websites, but because of the fact that I have a lot of contact with disabled people, I know how often they struggle using websites.
Why might knowing HTML and CSS be valuable to you?
In order to better design for accessibility and to understand why websites aren’t adapted to disabled users, I’ve decided to start learning the HTML and CSS languages. Unfortunately, I've noticed that most articles never mention the accessible implementation of HTML and CSS. It’s a shame because a lot of new frontend-developers who use these learning sources won't take into account crucial elements which could improve the accessibility of the websites they create. That’s why many websites lack lang attributes, correct heading structure, landmarks, form labels, alternative texts, and so on.
Remember that auditing isn’t just about validator tools.
Webaim conducted their evaluation using Wave validator. Nowadays, you can find a lot of free tools that are accommodated to browsers or operating systems. In my opinion, it’s good to use more than one if you want to evaluate a website because each tool focuses on different elements. (Usually, I make use of AXE, Wave and Andi.) Please bear in mind that these tools can’t evaluate your whole website accurately. Accessibility validators can display some of the failures which users may encounter using your website. However, you should evaluate received alerts yourself, because these tools tend to highlight failures incorrectly. For example, sometimes I get alerts about the contrast ratio being too low, when it actually isn’t. Besides, the validator tools never tell you whether the alternative text is written correctly, which is why you should always check the phrase meaning on your own.
Remember that the whole process of website evaluation should be based on the WCAG 2.1 guidelines, screen readers and if possible, on real users’ experience. You can treat the validator tools as additional support which helps you check if there‘s anything else you should focus on.
Improve your evaluation using screen readers.
Recently, I’ve started going through websites using NVDA or TalkBack to understand how assistive technology users can deal with this content. Sometimes, I ask my completely blind friend for help exploring a website because I don't have as much experience using assistive technology as she has. Unfortunately, in most cases, we both give up and leave the website.
Personally, I prefer the NVDA (Windows) and the TalkBack (Android) rather than the VoiceOver (Apple devices) but I think it might be related to how often I use them. Regardless, if you have the opportunity to use all of them, you’ll be able to notice how screen readers tend to interpret certain elements differently.
In my opinion, even the best specialists who use screen readers regularly and freely never have the same experience using websites as disabled people do. Of course, at times the budget can’t allow for usability testing. Still, it’s better to audit the websites on your own than not at all.
How can you carry on a quick evaluation of the website?
To show you what kind of failures you can encounter when auditing websites, I'll conduct a short audit using validator tools, screen readers and my knowledge. I’ll take Apple home page as an example. Why this website? Because their products are really good when it comes to accessibility features. So I’ve assumed that their website would, too! Let’s give it a try then!
(*I’m not auditing the whole website, I’d like to show you just a few examples from Apple's home page.)
List of failures and shortcomings:
1. No skip link - (You can check this element by using keyboard navigation. You simply have to click the ‘Tab button’. The skip link immediately appears on the page. Most of the time it’s located at the top-left corner or the top-center part of the website) Please read the Skip link article to find out how to implement the skip link correctly.
2. Very low colour contrast ratio (Sometimes it’s so noticeable that the contrast is too low that you don't need any additional tools to evaluate that. If you’re creating a report for clients, the good practice is to check the contrast ratio beforehand. (e.g. webaim colour contrast checker)
3.‘Learn more’ link - Using phrases, such as: “learn more”, “read more”, etc. may not be clear enough for users who struggle with cognitive impairments. In this case, for each “learn more” link an aria-label with description was added. Here follows the description that will be read by screen readers: ‘Learn more about iPhone 12.’
How can you audit this information?
- An aria-label which was implemented correctly is read by screen readers
- You can inspect the element. Here is a part of the code for one of the“learn more” links <a class="icon icon-after icon-chevronright" href="/uk/iphone-12/" target="_self" rel="follow" data-analytics-region="learn more" data-analytics-title="Learn more about iPhone 12" aria-label="Learn more about iPhone 12">Learn more</a>
- Some validator tools display the following information.
How could Apple make this part easier?
The 'Learn more' link could be named e.g. 'Go to iPhone12' - a comprehensible name for this element helps people with cognitive impairment. What’s more, an aria-label wouldn’t be needed anymore.
4. No interactive phone number - It’s a really common shortcoming which isn’t actually a WCAG failure. This example shows a phone number that looks like a paragraph that was added correctly but… We want to improve users' experience, don’t we? That’s why this element should be implemented as a link.
5. Heading 1 was placed before the navigation without a landmark. This isn’t a common practice, because:
a) Heading 1 should be placed in the main content in order to help users orientate themselves on the website.
b) Lack of consistency in the heading structure can be confusing for screen readers users, because only the home page contains h1 placed in this way, on the other pages h1 was implemented after the navigation.
Summary
Accessible solutions are of critical importance for people with limited abilities. If you’re creating a website for people with a particular disability you could ask them how their condition affects them while using your site. This might help you understand better what kind of solutions and practices you should avoid.
The short audit which I’ve conducted on the Apple website proved that their home page contains one of the most common failures from the Webaim list, which is very low colour contrast.
To avoid these kinds of failures and shortcomings, which negatively affect accessibility on your website, you should keep in mind the following:
- Never part with the WCAG guidelines which constitute the most valuable accessibility compendium containing additional information about how you can meet the requirements to better understand the application of the criteria at A, AA and AAA levels.
- Improve the evaluation using validator tools such as: axe, andi, wave, site improve and others that you consider valuable.
- If you’re a designer but you don’t have a technical background, I encourage you to read more about HTML and CSS because it might help you understand validator alerts.
- Screen readers are helpful if you need to check something quickly and you don’t have access to users. Nonetheless, I highly recommend testing websites with disabled people whenever possible. In my opinion, neither validator tools, nor using screen readers on your own will provide you with such valuable feedback and results as you can get from real users.
Sources:
Tools:
Be a part of
