You are here


A Quick Intro to Web Accessibility

nicholas.davison | Digitaria
By Nicholas Davison , Director of Web Development
Apr 16, 2012

This post will explain web accessibility and why it matters. It will lead you to some basic documents, tools and articles to get you started.

Accessibility is not just making websites for blind people. Other users who benefit from compliant websites:

•    The partially sighted, who can somewhat see the site but need accommodations to fully use it.
•    The colorblind, who can use the site but can’t tell your red dots from your green dots.
•    Deaf people can see a site just fine, but can’t hear sound effects in games, the soundtrack in videos or a buzzer that prompts 30-seconds left on a quiz.
•    Individuals who didn’t or barely graduated high school and can’t understand complex EULAs, ToS’ and privacy policies. They can’t find their way around a complex site, either.
•    Those with dyslexia or other comprehension difficulties may have trouble reading all of the text before a rotator moves on.

Why care?

That’s a lot of your audience: People still debate IE7 (~5 percent) and Safari (~6 percent) [source]. They started seriously considering the value of supporting Chrome when it first hit 5–10 percent. However, about 17 percent of Americans are disabled. We don’t ignore Safari’s user base. So why ignore a group that’s three times the size?

Good accessibility is generally good SEO:
Google and Bing are remarkably like a disabled user, having a hard time understanding a lot of your implied content. Spelling it out so it’s accessible spells it out for them and gets your rankings up -- bringing people to your site.

Because it’s (sort of) the law: The US government is very good at moving very slowly with specific web accessibility laws. However, Target settled their Americans with Disabilities Act (ADA) lawsuit for $6m over their online store being “a store” that didn’t “make reasonable accommodations.” Even if there aren’t explicit laws yet, defending yourself against an interpretation is still ruinously expensive.

Because more and more settlements require it: Even if the government doesn’t directly require it in law, a lot of legal settlements for other ADA violations often require ongoing accessibility compliance as part of their settlements.

Because government procurement requires it: Section 508 is the government’s own accessibility standard. It doesn’t apply to anyone else, but, if you want to build and sell a site to the US government, you are required to meet it.

So what do we need to do?

Good question. It would be great if there was a single set of requirements we could meet and know we were good. Unfortunately, there isn’t. We’re left with three main standards, all subtly different, so people pick what they feel works best for them.

Web Content Accessibility Guidelines 1.0 (WCAG1.0) -- The World Wide Web Consortium (W3C) is the acknowledged standards body for the web. They created WCAG1.0 some time ago, with three levels: A (basic), AA (intermediate), AAA (obsessive).
Pros: This was the first real international standard and provides a lot of testing tools and checklists.
Cons: However, it’s outdated and gets a bit unrealistic, particularly around AA and AAA where they often cover technologies that never emerged.

U.S. Department of Health & Human Services – Section 508 -- The U.S. government procurement standard. If you compare it to WCAG1.0 it’s blatantly a copy of 1.0 but clarifying what needed clarification and dumping what wasn’t needed.
Pros: Section 508 is cleaner than WCAG1.0 and is clearly the approved standard for the US government.
Cons: It’s U.S.-specific and quickly becoming outdated.

Web Content Accessibility Guidelines 2.0 (WCAG2.0) -- The W3C is revising WCAG to version 2. It covers more—a lot more. It’s also still in recommendation phase and not a final spec yet.
Pros: Version 2 is much more current, more detailed and covers more areas.
Cons: The 400 page core spec is unreadable. Many of the requirements are vague and hard to automate testing. There are checklists are coming, but they are less established.

    •    WebAIM -- WebAIM is probably the most useful single website for everything web accessibility related. Their checklists and validation tools are what tend to bring people at first but their articles are well worth reading.
    •    Other Checklists: Official W3C WCAG1.0 Checklist, WebAIM Section 508 Checklist, and WebAIM WCAG2.0 Checklist.
    •    Web Accessibility Evaluation Tool (WAVE) -- An online validator but even more useful if you install the Firefox toolbar. It’ll quickly show you a lot of what’s right and what needs fixing about a page.
    •    Web Developer Add-On -- The Web Developer Add-On for Firefox should be a must for most developers anyway. From an accessibility perspective, being able to hit Ctrl-Shift-S and instantly see the page without styles lets you quickly see pretty much what a screen reader sees.
    •    JAWS -- JAWS is probably the most commonly used screen reader and offers free demos on their site.