Designer’s Guide to the Basics of Web Accessibility Design

The web should be a place where everyone can access the same content from anywhere in the world. Responsive techniques have gone a long way for device-agnostic designs. But what about accessibility-agnostic designs?

Web accessibility has been around for years, but its implementation requires new advancements in technology and web development. Many developers want to help, but it’s tough understanding how to design for accessibility, because there are so many moving parts. This includes high-contrast text, audio pages for the blind, optimized media, and fallbacks for non-JS/CSS browsers.

In this post, I’ll cover the basics of accessibility design, what it is, what it aims to solve, and steps you can take to get started. Note, this is an incredibly detailed subject, and it will take months or years of practice to fully understand. But the benefits are worth the effort, and all of your web projects will leave every visitor with a lasting impression of accessible content.

Intro To Accessibility

Generally speaking, accessibility is the idea of building content so that it can be consumed by anyone. This may include blind people who can’t read, and it may include people with physical disabilities who can’t operate a mouse or keyboard (or either).

But it can also include people with slight deficiencies in vision. It might include people with dyslexia or reading comprehension issues. In fact, the idea of “web accessibility” includes every possible impairment that might affect how someone interacts with or consumes a website.

Perhaps more importantly is what web accessibility can offer, as described here in a Wikipedia definition:

Yet, Anne Gibson argues in her List Apart post that Wikipedia’s definition is too vague, and it’s not just about people with disabilities. It’s really about everyone on the web from all over the world that may not have optimal access to the Internet.

Many devs think that accessibility is just for blind people who can’t read. But there are actually four primary categories of web accessibility:

  1. Visual – low-vision or poor/no sight
  2. Auditory – hearing-impaired or deaf
  3. Cognitive – trouble comprehending or consuming information
  4. Motor – physical accessibility problems that may require special input devices like keyboards or voice command programs

These categories each have extensive techniques which are changing just as rapidly as web standards. But there is a sense of stability with these standards ratified into the WCAG (Web Content Accessibility Guidelines).

Some websites, like government institutions are required by law to follow these guidelines. They apply internationally through the W3C.

Let’s take a look at the bureaucracy behind web accessibility, and then dive into some applicable design tips.

The W3C & Accessible Design

There are quite a few acronyms related to web accessibility. These can be complicated if you’re brand new to the subject, but once simplified I hope they’ll make more sense.

Other guidelines exist under the WAI umbrella, including UAAG for user agents and ATAG for web authoring tools. For now, you should be most interested in the suggestions made by the WAI and the guidelines put forth by the WAI’s ruleset under the name WCAG.

A great resource for learning more is this post from W3C on disabilities, sharing stories of how disabled people access the Internet. It can be difficult to understand all the intricate problems, let alone understand how to solve them. But the best source is from people who face these problems daily.

Another important subject you should understand is WCAG conformance. This relates to a website’s level of accessibility covering a wide variety of factors. Levels are based on conformance with a rating system of A, AA, and AAA. You can check this with a web accessibility checker tool. The best score is AAA.

To learn more about these guidelines, check out W3C’s Introduction to Understanding WCAG 2.0 article. Also have a look at these related links for more details:

Steps To Accessible Design

I highly recommend visiting the A11Y project website for practical accessibility tips. A11Y (which is also a numeronym) is a free open source project hosted on GitHub, offering techniques for accessible web design.

You can browse their checklist of accessibility items, or even a bunch of design patterns for elements like dropdowns, tabs, accordions, buttons, and modal windows (among other items).

It’s difficult to learn all of this stuff and to implement it at the same time. Take it step-by-step, and be willing to research more if you get confused.

Check out the A11Y’s how-tos and quick tips for getting started. You’ll bump into specific suggestions like jump-to-content links and high-contrast color schemes. These techniques each have their own level of detail, so implementation is mostly about testing to see what works.

Consider blind users who may be using an automated content reader. They might also have an audio translator, or even a special keyboard for navigating the web with keys rather than a mouse. This is why proper semantic HTML (have a look at this article) is so important with properties like tabindex and accesskey.

If you want to dive in then consider picking up an accessibility-ready theme. You can study the architecture and customize the design to fit your project.

Accessibility Testing Tools

If you want to get started just pick an area of accessibility, and try it out. Then you can use testing tools to gauge your level of success.

It’s worth mentioning that this process can be frustrating. There’s so much to consider, and the WCAG guidelines are so hard to understand that you may end up with information overload.

The important thing is to just keep moving. Pick one area of accessibility, and make it your focus. Then use these tools to help you tweak and improve your work.

For example you might try working with the WCAG’s contrast specs to improve readability. Once you pick your colors, just use this free contrast ratio checker to see if they work together.

Unfortunately the WCAG 2.0 guidelines are so confusing that you may have difficulty understanding the requirements. But the more you try the more you’ll learn and the more you’ll understand.

For testing a site that’s already online check out WAVE. It’s a free visual checker that displays errors, alerts, contrast issues, and other specifics of a website. You’ll get a visual view and a list of issues in the sidebar.

There’s another free app on the Cynthia Says website which can check websites for WCAG success ratings of A, AA, AAA, and section 508 for government compliance.

And if you’re into open source take a look at these free accessibility testing tools on GitHub.

IMAGE: HTML Code Sniffer

Browser Add-ons

Browser add-ons likely provide the quickest and easiest methods for accessibility testing. You can run these from any computer on any website to get genuinely useful results.

AInspector for Firefox is regarded as a must-have for accessibility. This checks everything, and it’s much more thorough than the WAVE tester.

Mozilla users might also like the WCAG Contrast Checker which is also a free add-on.

Chrome users don’t have the AInspector, but they do have the Accessibility Developer Tools created officially by Google. This adds extra tools into the inspector window for checking accessibility guidelines.

Chrome users also have luminosity checkers for color contrast, and some other free extensions.

Unfortunately I couldn’t find much for Safari users, but I did find one extension for Opera that checks against WCAG 2.0 compliance. If you’re willing to search Google hard enough you might find more tools out there.

Further Reading

If you’re serious about learning web accessibility then be prepared for a long road. It’s not easy but it is very fulfilling.

By now you should understand more about the actual definition of web accessibility, why it exists, and minor details of what developers are expected to do to improve their websites. The next step is further research and practice to ingrain these principles into your workflow.

Check out the following posts for more info, and be sure to consult the WCAG guidelines if you want knowledge directly from the source.