Make Your Site More Accessible

Table of Contents

Why bother?
Concrete first, Catchphrase last
Readable links
Semantic HTML(5)
JavaScript is not enabled
Alt attribute on images
CAPTCHA. Just don't.
Labels for input elements
Other tips

This article is based on the WCAG 2.0 (Web Content Accessibility Guidelines), a worth reading set of recommendations for making Web content more accessible, that is, more friendly for people with disabilities.

WCAG 2.0 is way too long for casual reading. That's why after I read the Polish Publication of Dominik Paszkiewicz I decided to list the most important accessibility rules for web developers, like you and me, too keep in mind while doing their work. Obvious or surprising, I Got a Feelin' they are rarely used in reality.

Why bother?

Primarily for putting a smile on those 5% of your users faces: with low vision, hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, and many other. It that doesn't speak to you:

Your website/application can be better indexed and ranked by search engines. Think about web crawlers: they act just like blind person using advanced screen reader.
An accessible website is always more usable for all the people. Usability and accessibility overlap each other in every way. That's even more important for sites where usability is the key, like shopping platforms or productivity tools.
As web developer I can swear that following accessibility rules results in solid, clean, and easy to refactor solutions. And what follows, less expensive to maintain and extend in longer term.
Making your website mobile-friendly in just one use-case. Given you followed accessibility rules, the transition should be smooth (sometimes it will even work out of the box). If you did it your, hacky way, well.. good luck with that.
Just because it doesn't cost you much effort, make you better web developer, and person.

Concrete first, Catchphrase last

Here is how both accessible and SEO-friendly title should look like:

It should exist.
It should not begin with repetitive phrase like site name.
It should be unique.

Take a look on bad designed titles:

And now on the good ones:

Home - www.myawesomesite.com
How to cook delicious cake - www.myawesomesite.com
Pictures of my Kitty - www.myawesomesite.com

If you are blind person using screen reader, what is the first thing you hear each time you load any page in the first set of titles? And in the second? Can you easily skip the repetitive part in the first case? Second case?

Readable links

Similarly to page titles, every link on page should be unique. Blind person browsing through page will often hear only the names of links, so naming them like click here or [link] is not the best idea.

The name of a link should make sense on it's own. I propose, every time you link to something, read blue text it in your mind, and consider whether it is descriptive enough.

The same thing goes for URLs, as they are often read by screen readers too. However, nowadays it is less of a problem because e.g. Wordpress supports pretty URLs out of the box (like on this page).

Semantic HTML(5)

You probably know already that tables should be only used for tabular data, and not for making whole websites, so let's leave it.

There are organisations creating accessible versions of their websites by stripping all HTML tags and leaving plain text only. That's just wrong. Every reasonable HTML5 tag you use makes your site more accessible. For screen readers:

<a>, <h1> , <nav> and family helps in navigating throughout the page.
<ul>, <ol>, and <li> clearly tell what is, and what is not a list.
<q> and <blockquote> indicate what should be read as an actual quote
<p>, <strong>, and <em> make speech synthesis more believable
<th>, <thead>, <tbody>, <caption>, summary="[table description]" tell about structure of table.
<abbr title="Poland">PL</abbr> helps to read abbreviations as full sentence.
ARIA roles complete HTML5 tags and attributes in terms of accessibility.
<html lang="en"> or <blockquote lang="pl"> result in proper pronunciation of web pages and single sentences.

The last one is quite important as web developers tend to use them at first by copy-pasting the template, but don't change it afterwards. Say you've translated your site to Polish, but left <html lang="en">. Guess in what language a basic screen reader is going to read this page. The same thing concerns quotes in foreign languages.

Get to know HTML5 elements and their semantics. As the rule of thumb, the more HTML5 you use, the more accessible your site is. Flash is forbidden. DOCs and PDFs (especially that scanned ones) are not recommended too. Just don't overthink your markup.

JavaScript is not enabled

My golden rule is: Let the site work without JavaScript. Ajax stuff comes later. And it's not only about browser support or accessibility. There are screen readers able to run JavaScript code, which properly used, may increase accessibility of your site.

The thing is, as I mentioned in introduction, applications written that way are easier to comprehend, maintain and extend. HTML-only application is solid, mobile-friendly and accessible out of the box. You can make it really fast with almost no effort.

Did you hear about unobstructive JavaScript movement? It's basically the same thing. You remove any scripts from markup, and make site work without client code trickery. Then, you gradually add enhancements like Ajax loading. Enough said.

Alt attribute on images

You probably know that rule, but keep forgetting. My suggestion is to do it the easy way:

Add alt attribute to images that link somewhere at the same time.
Add alt="" to the rest of them.

The first point is quite obvious. Screen readers cannot read text from images, so for disabled person normal navigation is impossible without descriptive alt attributes.

The second is less obvious, but just as important. Screen readers read often loud the URL of every image on your page. Why? Because without an alt attribute, the URL is the only way to get a clue what is on that image. For example apple.png, or happy-face.jpg. Unfortunately, as often the URLs are meaningless, like upper-right-corner.png. Add to them empty alt attribute they will be skipped by any screen reader.

Another way of dealing with alt attributes is to not using graphical navigation elements at all. I think that CSS3-styled buttons are more than enough. Whenever it's not possible, take a path of application like stumbleupon.com: rewrite the label below an image to image's alt attribute and anchor's title attribute. That should be more than enough:

<a href="#" title="Stumble Cool Youtube Trick!"><img alt="Stumble Cool Youtube Trick!" src="..."> </a>

Funny side note: imagine screen readers 10 years ago, translating to human language some website based on tables and tons of blank-pixel.gif

CAPTCHA. Just don't.

The best moment to use CAPTCHA is like never. It's the plague of the Internet. Generated images securing web forms are not readable by neither people with low vision nor people suffering from attention deficit disorder (frankly as well as those healthy too).

Yes, services like captcha.net provide an audio version of CAPTCHA, but it isn't less harder to read (and often not accessible only from keyboard, using Flash etc.)

If you need to secure your form, there are good alternatives:

Akismet.com for SPAM prevention (Polish readers should be interested in sblam.pl).
Honeypot and form hashing techniques.
IP addresses monitoring.

If you really need to use CAPTCHA, for example on log in forms, hide it on first or second attempt. Your users will be grateful for saved time and bots won't crack any passwords.

Labels for input elements

Although screen readers are good at guessing, they require connecting label elements with input tags following way:

<label for="first-name">First Name</label> <input id="first-name" />

If you use Rails, Django, Symfony or other fancy web framework it is often done for you. Sadly as often I see it missing, especially on commercial websites.

Other tips

Make your damn menu navigation accessible from keyboard.
NEVER WRITE IN CAPS. Screen readers cannot distinguish them from abbreviations.
Divide content into paragraphs, and sections with headers. No one likes monolithic essays.
Do not use justified text. It looks pretty on design, but is horrible to read, especially for people with low concentration. If every line ends in different place it's easy to know where you got lost.
Don't use italic on more than few words. Some people find such sentenced very hard to read.
If you are designer, use at least 13px font size and reasonable text contrast.
Use subtitles for your videos and transcripts for audio files, if possible. Take a look at this Ruby Rogues Podcast
Ensure that focus is visible on each input. That is the default for example in Chrome. It's good thing to create an enchanted focus, like on navigation of dostepnestrony.pl site.
If you don't use something like HAML or SLIM, mill the page through W3C Validator. Screen readers and Google Bot will be thankful.
If your site supports keyboard shortcuts, high contrast versions, or +/- buttons, it doesn't really mean it's accessible.

Adam Stankiewicz