Websites with standards-compliant code all follow the typical W3C standards. But there’s a whole different level of compliance when it comes to WCAG, also known as the Web Content Accessibility Guidelines.

The same people who produce the HTML5/CSS3 specs organize and officiate these guidelines, so it’s truly an international system of coding standards. Most web developers never bother with WCAG accessibility, but it’s becoming a huge aspect of the internet.

This post was originally published on Vandelay Design.

If you’re looking to understand accessibility or just want to delve a bit deeper into the subject, then this guide is for you. I’ll explain some basics of WCAG conformance for a beginner, along with all the tools and resources you’ll need to keep learning along the way.

Intro to WCAG

The Web Content Accessibility Guidelines follow the current v2.0 spec requirements for accessible websites. This page explains the absolute fundamental concepts without getting into too much technical detail. The W3C/WAI website is the absolute best resource for information on this subject.

“Give all users the best experience possible regardless of limitations or disabilities.”

I’d also like to clarify that there are levels of compatibility when it comes to content accessibility. You don’t need to be a AAA perfect site to be considered accessible. Follow some basic tenets set in the WCAG, and you’ll significantly improve the experience for millions of people.

Here’s a rundown of some crucial guidelines to follow for modern web accessibility:

Text alternatives and captions for non-text media (videos and images)

Allow users to traverse the page with only the keyboard

Give users control over which features to load or change

Design page text with sufficient contrast

Other common accessibility points include allowing visitors increase text size and giving visitors the option to disable JS/CSS without destroying usability. This can move into the territory of progressive enhancement, which goes hand-in-hand with accessibility.

WCAG conformance

As you can tell from the best practices page, there’s a lot that goes into web accessibility. The topic continues to grow, and it can take years to master all of this stuff.

If you want to dive in, check out this guide published by the WCAG 2.0 team. It covers all the specific areas you’d need to learn about for all levels of conformance.

But thankfully you don’t need to master all of this stuff, because even basic accessibility practices can go a long way to improving the overall usability on any website.

The goal here isn’t to pass a WCAG test, although that’s definitely good. But rather your goal should be to give all users the best experience possible regardless of limitations or disabilities.

“Allow users to traverse the page with only the keyboard.”

WCAG ratings are called conformance levels and they define a website’s overall success in relation to accessibility parameters. The WCAG 2.0 spec has a conformance page explaining the 5 necessary requirements of an accessible website:

A grading level of conformance must be met with either A, AA, or AAA The full webpage must conform to standards, not just a part of the page Related process pages must all conform to the same rating or higher to be considered accessible(for example, an eCommerce checkout process) Accessibility must be achieved by use of supported technologies deemed credible by the WCAG It’s possible to use technologies that are not fully accessible, so long as the content is still accessible with a different technology (for example, a Flash video with a supplementary text transcript)

The WCAG defines these 5 requirements as vital to the success of a webpage. It’s still possible to pass a conformance test with a single A rating—in fact that’d be better than most sites.

But some sites have limitations where they must hit a minimum of AA or AAA. This is mostly in the realm of public companies like government agencies, so private companies don’t need to worry as much.

The conformance scale works like this: You score a single A rating when you hit all priority-1 checkpoints. Priority 1 and 2 earns the AA rating, while AAA is reserved for sites that conform to priority 1-3 requirements. Take a look at the full WCAG checklist to learn more.

It’s incredibly lengthy, and this topic could easily be published into a tome of information. I’d like to just cover a handful of vital steps in the process to get you started on the right path towards web accessibility.

Navigation and consumption

All content on the page should be easy to read and consume. This obviously means proper grammar and correct spelling, but also content location and text size.

Accessible text follows some general rules specified in the WCAG 2.0 quick reference guide:

Text is never aligned justified

Text should be able to dynamically resize without requiring the user to scroll horizontally

Line spacing between lines of text should be at least a space-and-a-half depending on text size

Spaces between paragraphs should be at least 1.5x larger than line height

These guidelines are made by the WAI/WCAG and should be followed strictly to adhere with global standards. Since the standards can be applied in scale, it’s easy to follow these rules for any type of text, from headers to paragraphs and tiny captions.

There’s also a strict method of selecting contrast ratios, which is covered in depth in the next section.

Check out Will Howe’s accessibility menu design on Dribbble.

Let’s not forget about navigation design and usability. Not all users have mice, or they may not be able to use a mouse, so the keyboard is the next-best option.

Even though it’s a tough spec to meet, the WCAG recommends that compliant websites support keyboard accessibility for all common website features. This includes navigation menus, page hyperlinks, and input fields for web forms.

“Keep in mind that some users aren’t able to use a mouse.”

Naturally this technique could rely heavily on JavaScript, and many people have written about keyboard accessibility for alternate tips.

It’s often best to start with a list of features and plan each one in advance. This way you’ll have more confidence when designing a new site and placing accessibility at the forefront.

Perhaps the best line of success is to provide keyboard shortcuts for all major functionality. This can include a clear navigation menu but also links for jumping to main content.

Take a peek at the official guides provided by the Web Accessibility Initiative (WAI). They control the WCAG guidelines and want to provide as much help as possible.

Text contrast ratios

Design text contrast for your layouts while checking against WCAG metrics for visual content. This requires free tools like a contrast checker to figure out your color and background ratio.

But it’s a very simple procedure that can greatly increase your website’s accessibility with just a few changes.

The WCAG checks colors based on a luminosity ratio of 3:1 for larger text, and 4.5:1 for smaller text. This ratio measures the luminosity of background and foreground colors using some complicated math to attain a ratio value.

This ratio defines contrast for accessibility and gives web designers a number to shoot for. You probably don’t need to worry much about the numbers, but rather should just try colors and see which combinations work best.

Once you have some colors you’ll want to use contrast tools for checking your work. The open source contrast ratio checker on GitHub is a popular choice.

Check out Lea Verou’s work on Github.

But there’s also many free web apps like ContrastChecker.com and Check My Colours. The benefit of these sites lies in the details.

For example, Check My Colours will check an entire live webpage. The GitHub ratio checker only works on two colors that you manually input into the page. Both are very useful but for different reasons at different stages of the creative process.

This Chrome extension analyzes color contrast.

If you don’t want to use web apps, try browser add-ons instead. My recommendations are the WCAG contrast checker for Firefox and the Color Contrast Analyzer for Chrome.

Content organization

It’s easy to get lost in CSS floats and custom hacks, and forget the value of semantic HTML. Accessibility guidelines dictate that content should follow a logical focus order where headers, paragraphs, and sub-headers should be organized based on content direction.

Not all users will have the full CSS experience. Just because content floats a certain way doesn’t mean it’ll be consumed that way by everyone.

Consider following the progressive enhancement model where you disable CSS and JS completely while first building a layout. Examine how the site looks as just raw HTML. Can you follow the content in a logical manner? If so, then your content is built perfectly.

If you want to improve content recognition, the WCAG also recommends location markers like breadcrumbs. These keep visitors in tune with their current location and other parent pages on the website.

Gov.uk’s breadcrumbs accessibility.

This can also be clarified by providing multi-page headers and a clear site map. All of these techniques are great for hitting that AAA score.

Do everything you can to organize text in a clear fashion , regardless of technologies available to the visitor.

Learning resources

If you’re looking to follow WCAG rulesets, you’ll want to pay attention to requirements with testing tools. There are dozens of third-party tools online, and they all help with different aspects of the testing process.

But I’d like to give an honorable mention to this tools list hosted by the W3C/WAI website. It’s full of great resources, and while it’s very long, it’s the best place to start searching for a tool that’ll fulfill your exact needs.

“Do everything you can to organize text in a clear fashion.”

It’s tough to use tools if you don’t know exactly what you need. So perhaps the best place to start is a free online cheatsheet. I really like Viget’s interactive sheet with dynamic elements for A, AA, and AAA ratings.

Here’s a technical cheatsheet offering code snippets and technical explanations. Follow whatever method is going to help you find exactly what features you want to support and how much you want to conform to WCAG 2.0.

Once you’ve fixed up your site, test it. For live testing tools, try WAVE or Achecker—they’re both completely free.

A screenshot of WAVE in action.

I prefer WAVE because it’s simpler but offers many more features. You get warnings and alerts based on content issues with the site, and you can even check other sites to see how they compare to your own.

Accessible Website Design Examples has tons of—you guessed it—great examples.

I highly recommend browsing this site for accessibility resources and live examples. You’ll find tables, galleries, and other common page elements built with accessibility in mind.

By studying how they should work on a real site, you’ll learn how to implement elements in your own projects. Getting started is never easy, but it helps to have quality examples at your disposal to study and replicate as needed.

I also like this post by Terrill Thompson—it covers accessible websites in more detail. Terrill provides live examples, including many US government websites that are required to follow 508 accessibility guidelines.

Understanding WCAG and learning to build compliant websites will take years of practice. Developers who take this seriously understand how important it is. But that doesn’t mean you need to make websites that are fully WCAG compliant.

Even a basic understanding of contrast and font size adjustments are enough to make your sites consumable by a wider audience.