Skip to the code: Codepen (opens in a new window)
Has it already been a year? It sure has!
Here we are again. Turning that same old wheel, talking about the same old accessibility issues. But hey, it keeps me busy, that’s for sure.
For those not in the know, the WebAIM Million is a yearly scan of the top 1,000,000 web homepages for accessibility failures using the WAVE automated tool. The big list of sites was provided by the Majestic Million with some supplemental information from other big tracking websites.
What’s neat is that this is just the landing page of these URLs. That’s it. We’re not even digging into the meat and potatoes of the site, just the outer packaging.
The top most common WCAG Failures:
- Low contrast text (1.4.3: Contrast) — 86.4% of sites
- Missing alternative text for images (1.1.1: Non-text Content) — 60.6% of sites
- Missing form input labels (3.3.2: Labels or Instructions) — 54.4% of sites
- Empty links (2.4.4: Link Purpose) — 51.3% of sites
- Missing document language (3.1.1: Language of Page) — 28.9% of sites
- Empty buttons (4.1.2: Name, Role, Value) — 26.9% of sites
My favorite part is that these are all WCAG Level A criteria except #1. How is it 2021 and we’re still talking about meeting Level A?
How to fix the issues
Low contrast text
Do you enjoy squinting trying to read text on screen? Neither does anybody else.
There’s this great tool out there called the Colour Contrast Analyzer that was made exactly for this purpose. You put in the two colours using the eyedropper or by entering the hex values and you’ve solved your problem.
Still having issues? Browsers to the rescue.
Firefox has an integrated widget in their dev tools that allow you to see the contrast of the text you’re putting on your page. It’s easy. Really easy and it only takes a second. But if possible, you should have your design standards audited for colour contrasts and never think about it again.
Missing alternative text for images
Are we still talking about alt text? that’s okay, it’s more complex than it looks which is another reason why AI isn’t going to take over alt text any time soon.
Sometimes you need something descriptive, other times you need to just enter the text in the image, other times you just leave it blank.
Rule of thumb: Does this graphic matter to the page? Is it important to the user’s understanding? is it a logo? then you probably need alt text.
There are lots of great articles written on alt text that the internet doesn’t need another one. Moz wrote a great one because it also talks about SEO.
Missing form input labels
Every input needs a label. Full stop. Without it, screen reader users don’t know what the input is all about. It’s just a blank input.
There are generally 4 kinds of labels out there:
<label for=”fname”>First name:</label><input type=”text” id="fname">
<label>First Name:<input type=”text”></label>
<span id=”fname”>First Name:</span><input type=”text” aria-labelledby=”fname”>
Aria-label (replaces label for screen readers and is not visible):
<input type=”button” value=”X” aria-label=”close window”>
Only you can decide which one is best for your application and the underlying code, although I do tend to recommend the
<label for=””> for most applications since it’s more flexible than the other methods.
Are we talking about links of images or icons? That means that you kill two birds with one stone by just putting alt text on the image since a screen reader and browser audit tool will pick up the text in it.
Example of social icons:
<a href=”example.com”><i class=”fa fa-twitter” aria-hidden=”true”></i> <span class=”sr-only”>The A11y Coder Twitter page</span></a>
Missing document language
This is perhaps the easiest of all, and it helps so much. Especially if your site is in a different language (hello fellow Canadians).
Pretty much any element can take the
lang attribute, and it’s important because screen readers look for this attribute so that it can read out the content of the document in the specified language. A screen reader can’t tell the difference between different languages on the page. Only a developer can define this.
At the page level, all you need to do is add
lang=”en” to the
<html> of your page (for English). This can also be toggled to a different language through various i18n (internationalization) repos as well. For example, to change to French, you’d need to change this to
lang=”fr”. Bonus: if you have certain elements on a page that are in a different language, you can also just add the
lang attribute to that element as well.
The end result of this allows screen readers to read out the page in a native sounding accent. It’s also a requirement according to the W3 specification.
This one is going to be as easy as the Empty Links issue above. We’re yet again looking at the most likely cause being icons or graphics without alt text. Here’s how to fix it:
<img src="theA11yCoderLogo.jpg alt="The A11y Coder">
One thing I would like to mention is that these are the lowest hanging fruit that you could be asking for to get working on accessibility. It doesn’t take any special knowledge or skills and hey, you can even find them all using free automated tools such as Wave or Axe. There’s really no excuse here (sorry).
The main point I would like to drive home here is that we, as developers, are the last gate before the product is released to the user. Our skills and knowledge of basic web programming are what can make or break a user’s ability to navigate the site (and potential litigation). It’s time that we commit to building code as per the W3 HTML specification. A browser will attempt to display whatever we put in the code editor, but that doesn’t mean it’s correct.
Disagree with anything I’ve said here? Great! Add some comments to this article and we’ll have a learning session!