ALT-TEXT

This is one of the most important forms of web-accessibility in my opinion, and for a couple of reasons:

First, it’s incredibly simple to implement — hell if you’re like me, and use Emmet, it automatically adds the alt parameter in your img tags, leaving you only with the task of coming up with how to describe the image which contrary to some peoples opinions, is not hard to do.

Secondly, this is one of those accessibility standards that potentially improves the overall experience for each your users, regardless if they posses accessibility issues or not. If you are like me, and a lot of other developers, you like to host most of your static resources on a CDN. What happens if the S3 bucket hosting all your images goes down? Well if you were designing your site with the basics of accessibility in mind to begin with you, you would have added alt-text to your images, and your users will at least have some semblance of what should be there.

On that note I would like to take this opportunity to address a common complaint I have come across when discussing the use of alt-text on images:

You are not required to have alt-text for every image on your site.

Decorative images do not need a description, though realistically speaking you should not be using images for your styling in the first place; images should only be used when trying to convey information of some kind. The specifics here are a topic for another day, and maybe another article altogether.

If there is one thing I can stress here - if you’re going to implement any accessibility features, at the very least ensure the proper usage of alt-text and…

LABELS

I’ve heard the question “Why use labels?” asked with a complete lack of irony far more than I’m comfortable admitting. The frequency of this question informs us of at least one possibility:

People have no idea why they are doing half of what it is they are doing.

Now if you’re like me, “because” is not only an unacceptable answer to a “why” question, but one that can provoke an almost visceral reaction. You need to know exactly why you’re doing something, down to every atomic rationality, otherwise what’s the point?! When it comes to not only labels, but a lot of things in HTML, a StackOverflow user by the name of MrMisterMan put it rather succinctly:

HTML is not about presentation. It is a way of describing data. If you have some text that represents a label for an input, you wrap it in label tags not for presentation but because that’s what it is. Without the label tag, that text is almost meaningless. With the label tag and its for attribute (or not*) you are providing meaning and structure and forming a relationship between your markup that can be better understood by computers/parsers/browsers/people. * you don’t necessarily need the for if you wrap the label around the input

Now that’s what I’m talking about! Simply put, use of the label tag where appropriate allows users with screen-readers to understand the controls that exist on a page. While typically they are only used on forms, they are valid when used with any phrasing content ( a , span , canvas etc).

ARIA LANDMARKS

This has the potential to be the one that draws the most ire, and confusion, but it’s important. Most of the HTML5 sectioning tags by default define ARIA landmark roles, so both often don’t need to be used, though like anything there is an exception to this rule. There are some key differences between a few of the HTML5 tags, and what may be perceived as their ARIA landmark equivalent, but first here’s the interchangeable bits:

aside === complementary

=== form === form as long as there is a title attribute present

=== as long as there is a attribute present main === main

=== nav === navigation

=== section === region as long as there is a title attribute present

Here is a couple gotcha scenarios:

header === banner , and footer === contentinfo , but only when they are a direct descendent of body

Now you’re probably left wondering what ARIA landmark roles are left to use, well, there are at least a couple:

role=search is used to define a search landmark. There is no equivalent HTML5 tag, so be sure to use it whenever applicable

is used to define a search landmark. There is no equivalent HTML5 tag, so be sure to use it whenever applicable role=checkbox is used to let a users assistive tech understand there is a checkbox present. It should be further expanded on by adding either aria-checked="false" or "true" so that the user also knows the present state of the checkbox.

CONTRAST

Does the text on your page look like this?

Well then it sucks. Big time. Not only is this next to impossible (in some cases entirely so) to read for people with visibility issues, it’s extremely hard to read for those on mobile, or with poor displays. Text on websites should at have a contrast ratio of at least 4.5:1, though 7:1 would be ideal. Use discretion here, but don’t just settle for good enough. For the record, the above example clocks in at 2:1.

Because I will concede that constantly validating your colour profiles with tools such as the WebAIM CTontrast Checker would in fact be rather time consuming, here is a handy little example of what varying contrast levels look like:

LINK CONTENT

Links should be meaningful, and the text that composes them should indicate exactly what content the user is about to be directed to. Take a look at the links throughout this article: notice how, without clicking on any of the links, you have a pretty good idea where it’s going to take you. So that means no links simply saying “click here” or “this” as that does not give the user any indication of content. That doesn’t mean you are required to write eloquent prose describing every single link on your page, just enough that the user has an idea what link they’re focused on without any context.

AUDIO/VIDEO

If you have information you are trying to convey to the user, try to avoid using audio or video to do so. If it is unavoidable for whatever reason, ensure that you are offering transcripts of the audio/video so that users with hearing or vision problems have access to the content as well. Let’s be real here for a second; videos as decorative elements on a site are tacky, and really does nothing to improve the overall user experience, regardless of accessibility level.

ROOT-LANGUAGE

And last, but not least, arguably the easiest to implement is the root-language of your document. Wanna know just how easy it is? So easy you’ve likely been doing it this whole time without even realising it!

<html lang="en">

That’s it! I mean of course you will need to ensure you are selecting the correct language for the region your document is being created for, but I’m certain you get the gist of it. This ensures that screen reading software can utilise the correct region specific pronunciation/spelling, eg. the difference in the pronunciation, and spelling of aluminum/aluminium between British and American English. If for some reason you were still in need of some, here are a few more reasons outside of the accessibility use case for ensuring you’ve set your documents root language correctly:

Informing the browser of the correct spelling to use when spell-checking is enabled

Ensuring the correct text direction, and default font set is used

There you have it, yet another accessibility basic you now have no reason not to implement!