Earlier this year, I was about to start working on a new project, when I was told that it would have to meet certain accessibility requirements (in this case it was ADA Section 508). At first, I wasn't really too worried about it. As long as my code was clean and I didn't do anything too stupid, it would be no big deal… right? Well, reading up on the standards confirmed that making a site decently accessible means that there's a lot more to it than just remembering alt tags.

Defining Accessibility

We developers like to talk a lot about accessibility, but what does it actually mean? The W3C’s page on accessibility sums it up fairly well:

“It is essential that the Web be accessible in order to provide equal access and equal opportunity to people with diverse abilities. Indeed, the UN Convention on the Rights of Persons with Disabilities recognizes access to information and communications technologies, including the Web, as a basic human right. Accessibility supports social inclusion for people with disabilities as well as others, such as older people, people in rural areas, and people in developing countries.”

Basically, this means that all sorts of people should be able to access your site, and not just a lucky few. With that in mind, here are some things that I discovered about accessibility over the last few months.

jQuery plugins: friend or foe?

I’m not going to lie — I like using a good jQuery plugin here and there since it can save a ton of time in implementing all sorts of interactive features. However, when it comes to creating an accessible site, a lot of these “awesome” plugins won’t actually work properly. I’m not going to name and shame here, but if you’re trying to build an accessible site, do yourself a favour and try out any plugin you’re considering using only your keyboard instead of your mouse. Sadly, many plugins totally crumble when put to this test. In some cases, it isn’t a huge deal because the plugin can be modified fairly easily, but in other cases, you might need to scrap it altogether.

Takeaway: You might have to write more custom JavaScript, but that’s okay. You’re a web developer and you like writing JavaScript, right?

Accessibility is in the details

Applying the concepts of accessibility in practice will make most people think about things they never considered before. What’s it really like to navigate a website exclusively with your keyboard? What will your colour palette look like to people who aren’t using nice new displays with good contrast — or to someone with colour blindness? Will people who need to zoom in on the website be using browser zoom or changing their browser’s default text size, and what does that mean for your web typography choices? How will people who can’t hear experience audio or video on your site — do you have transcripts prepared? Are your icons and symbols properly labeled so all users can understand your website? Making a site accessible doesn’t necessarily have to be about grand gestures – the little things add up to achieve big accessibility wins.

Takeaway: Making a website accessible doesn’t just help those with disabilities use your site; it can help anybody have a better experience by making your site easier to use and understand.

Some famous logos, as seen through the Sim Daltonism colour blindness simulator. It's important to ask yourself whether your design is still understandable without all of its original colours.
According to the colour contrast checker at snook.ca, the text on the left doesn't make the cut, while the text on the right is good to go.

Yes, semantics really do matter

As a developer, I always strive to make my code as clean, clear and semantic as possible, but I never fully realized the importance of semantic code to clients and users until I had to make accessibility a top priority. I knew, of course, that semantic code was important to fellow developers who might be working with the code, but it’s also a huge benefit to any user that’s accessing a site by listening to a screen reader. In particular, using the right heading tags to divide content into proper sections is essential since most screen readers allow users to navigate by jumping from heading to heading. Think of it like being able to see a book’s table of contents and skipping right to the section you’re interested in, as opposed to having to read through a book from cover to cover in order to find what you’re looking for. If you’re curious about what your site’s “table of contents” looks like, run it through the HTML5 Outliner or use Google’s extension or bookmarklet. For further reading, check out Designing for Screen Reader Compatibility on webaim.org.

Takeaway: Semantic code isn’t just for developers — it often helps users just as much.

In conclusion…

My biggest overall takeaway from this experience was how inaccessible many sites are, and how frustrating it must be to a person with certain disabilities to regularly have poor web experiences. As developers, it’s our job to keep this in mind when creating any site, whether it “needs to be accessible” or not. You can bet that these lessons are being baked back into our work. Hopefully some of these will make it into your next projects as well.

  • anne-marie

    Great article. My job is dedicated to making accessible websites for one of the school boards outside of the GTA. Great resources provided, hopefully this will put a bug in some peoples’ ears about the benefits of an accessible site.