Alright folks, I think I’ve done a pretty good job of beating the workflow stuff into the ground, so I thought this time around I’d change gears a bit. Developers are interesting in that, for the most part, they’re extremely territorial and opinionated when it comes to their build tools, the languages they use, and even something as (seemingly) trivial as the amount of spaces used for tabs (if you’ve ever wanted to induce a riot at a developer event, voice your opinion on this).
Despite all that, there is one phrase that is guarantee to unify developers across the board and possibly induce a few heart palpitations:
“is it accessible?”
Accessibility is typically a topic that’s brought up begrudgingly either out of necessity or fear. This of course raises it’s own questions, but let’s first tackle the most obvious issue of them all:what exactly is accessibility?
Luckily for us, the definition is fairly easy to point down: making sure that the content of your site can be accessed by anyone, including those who use things like screen readers or other assistive technologies. So, how do we go about doing that? Super easy, right? All you have to do is throw this tag in the head of your document and you’re ready to go, right?
Move along, this isn’t the tag we’re looking for
Unfortunately, making your site accessible is not one thing, but many things working together. Before we get into the nitty gritty of how to make your site accessible, let’s first begin by talking about why you would want to do that in the first place.
I’m going to set aside any moral arguments for why you would want to do this thing and tackle it on pragmatic grounds.
The first reason being that your demographic may warrant it. Unfortunately, it’s not possible (as far as I am aware) to accurately track how many users are coming to your site who use a screen reader. Most people associate using a screen reader with someone who may be differently-abled and can’t physically read text off the screen and need the content dictated to them – hence the need for a screen reader. The most linear connection to a user would be someone who may be blind, but that is not always the case. For instance, many elderly people who have trouble reading words off the screen need the assistance of a screen reader and may use the keyboard (as is common for those who are visually impaired) to navigate through the website. If a large portion of your site’s userbase are elderly, then it may be worth investing some time in ensuring that your site is fully accessible.
It’s the Law
The second reason being that it’s the law (if you’re in Ontario, that is: source). This is especially pressing if you’re operating a business with 50+ employees, as your site will need to conform to WCAG 2.0 Level A standards as of 2014, and as of 2021 will have to conform to WCAG 2.0 Level AA standards. You can read more about the WCAG 2.0 standards here, and more on how to meet them here.
Lastly, making your site accessible will (along with many other things) will help with SEO, ultimately generating higher rankings in search engines, generating more sales, and making all parties happy.
Now, looking at the links I posted above, the task of making your site accessible can seem incredibly daunting. While it’s true that there are lots of small components to be mindful of, many of them are things that you are likely already – and at the very least, you should – be doing. Things like including alt attributes on img tags and title attributes on a tags will go a long way in ensuring that navigating your site is a much more pleasurable experience for those who use screen readers.
While I’m no means the expert on all things accessibility related, there are a few things I’ve discovered and a few things I always try and be mindful of when developing a site. This will by no means be an encyclopedic post, but rather an introduction to the idea of little things that you can do that will go a long way to making your site meeting the necessary standards.
First and foremost, as I already mentioned, you should absolutely be including alt and title tags on img and a tags. This is a non-negotiable as it is both easy to remember, implement, and an extremely low barrier to entry to the world of accessibility.
These can often get overlooked as the most pressing attribute to add onto either of these tags is the src or href attribute, respectively. However, since these attributes should be included on every instance of that element, I would recommend setting up a snippet for that to both expedite your workflow and, as an added bonus, will also up your accessibility game. I’ve covered making a snippet in Sublime Text here if you need a refresher.
Another big-time pain point is form elements. A lot of more modern designs have done away with labels – shorter forms are generally seen as a lower barrier to entry, and thus have a higher conversion rate – and as labels occupy a good amount of space, can be seen as a detriment. This can lead to not including labels at all in your markup, which you should not do. The label, well… acts as a label for the input, and without it, it is much harder for a screen reader to interpret what an input is to be used for. It should also be noted that the placeholder attribute is not a substitute for a label.
So, this puts you in a real pickle, right? Well, not exactly. You can still include the label in your markup, but simply hide it from the user (this also applies to checkbox/radio elements that you would like to hide visually, but still want behind the scenes). Now, this is where the method is very important. The most obvious solution to this would be to use display: none;, however, screen readers will not be able to read these elements. You could use visibility: hidden; position: absolute; left: -9999%;, but I prefer to skip the visibility: hidden; (especially for the aforementioned checkbox/radio elements) as some form validators (including the validator packaged with Magento) check for visibility as a requirement.
It’s also worth noting that in order for a label and an input/select to be bound to one another, the for attribute of your label must be set to the id attribute of the element you wish to bind it to.
Accessible Rich Internet Applications
Lastly, I’d like to touch on a lesser-known protocol: Accessible Rich Internet Applications (ARIA). While there’s a lot to how you can use this protocol, and all it’s various attributes, let’s keep in line with the theme of this post: baby steps.
Let’s just start with the role attribute for now. What this does is add more descriptive content to your elements, so a screen reader can more accurately portray what is in the browser.
So where would you use this? Well, let’s say that you have a div that contains all of your content. This wouldn’t be explicitly clear just by having a class of “container” or something similar on it. However, specifying that the role of this div is the container by adding role="container" would greatly help in conveying that.
A more pertinent example would be something like a navigation. Typically, this is done through a ul element, and even if you have a class of “nav” or “navigation” on the element, it’s still not explicitly clear to a screen reader that the purpose is to serve as a navigation. Throw a good ol’ role="navigation" on there, and you’ll be in much better shape. For those wondering, I would still include this attribute even if you were using a nav element – it can’t hurt, and being more explicit will only help you along.
Accessibility and eCommerce
Hopefully I’ve given you something to ponder over, and pointed you in the right direction with regard to stepping up your accessibility game. There’s a lot of things to take into consideration, and I hope that this post will at least point you in the right direction. If there’s anything that you would like to hear more about, or any points you’d like clarified, please don’t hesitate to write in the comments below!