Introduction
Last modified on Fri 17 Mar 2023

What are guidelines?

In the next two chapters, we'll be covering accessibility guidelines. Therefore, it's worth noting what those guidelines are, how you should approach them, and what you can refer to.

We'll refer to sets of rules regarding accessibility practices on the web as guidelines, and we'll define exactly what is meant by the word guideline in the context of standards below - following the WCAG definition of those terms throughout the Web Accessibility Handbook.

WCAG in general

WCAG, the Web Content Accessibility Guidelines, are an international standard for building accessible sites and applications for the web. They're developed by the Web Accessibility Initiative, an initiative of the W3C, through an open process.

Due to their scope, details, continued improvements, and many examples, they've become the standard for accessibility. For instance, the Harmonised European Standard: Accessibility requirements for ICT products and services, which is the implementation standard for accessibility requirements in the EU, requires sites to be WCAG 2.1-compliant. WCAG 2.0 is also an ISO standard (ISO/IEC 40500:2012).

WCAG is a versioned standard, with currently published and relevant versions being WCAG 2.0 and 2.1, and 2.2 in the making and scheduled [a][b]for 2023.

Major WCAG versions are backward-compatible: content conforming to WCAG 2.1 also conforms to WCAG 2.0. The Web Accessibility Handbook is based upon WCAG 2.1.

We encourage you to reference WCAG when building things for the web.

Levels

WCAG has three levels of requirements, increasing in their scope and difficulty to support, with Level A being the lowest level and Level AAA being the highest. Each level includes the success criteria from the lower levels. Don't worry if the words "success criteria" don't make sense yet.

Level A compliance is mostly covered by writing good code, and it shouldn't be difficult to support. If it is, you're probably approaching something wrong.

Level AA requires some support work but provides many impactful success criteria for users with disabilities and drastically improves their user experience.

Level AAA is quite difficult to implement properly and is meant for fully accessible web content. Therefore, it includes very strict requirements, such as providing sign language interpretation for all prerecorded audio, and provides little to no exceptions. As per WCAG itself, it's not possible to satisfy all Level AAA success criteria for some content.

Therefore, we suggest aiming for Level AA compliance on projects, as it provides a great balance of the effort required and benefits to users.

We generally won't focus on Level AAA compliance. Still, we'll include some tips on following cherry-picked Level AAA criteria that won't impact the scope of your project drastically, such as supporting prefers-reduced-motion (which is covered under Level AAA Success Criterion 2.3.3. Animation from Interactions). If you support WCAG Level AAA in your projects, please refer to the standard.

Making sense of WCAG

WCAG is based upon four principles of accessibility, which lay the foundation for anyone to access and use web content.

Taking from Introduction to Understanding WCAG, anyone who wants to use the Web must have content that is:

Under each of the principles are guidelines and success criteria that help to address these principles for people with disabilities. Many general usability guidelines make content more usable by all people, including those with disabilities.

There are twelve guidelines in total, each addressing a specific concern regarding web accessibility for people with disabilities. Guidelines themselves are vague and broad; for instance, guideline 1.2., "Time-based Media", is as follows:

Provide alternatives for time-based media.

Therefore, guidelines aren't useful for implementing and following WCAG but instead serve as a sort-of categorization of success criteria and motivation.

Guidelines provide the basic goals that authors should work toward in order to make content more accessible to users with different disabilities. The guidelines are not testable but provide the framework and overall objectives to help authors understand the success criteria and better implement the techniques.

Each guideline is divided into success criteria, which are "rules" defining WCAG conformance. To meet a WCAG level, the content needs to meet all the success criteria for that level and preceding levels (or provide a conforming alternative version, but let's not do that).

Success Criteria are specific, testable requirements that define what must be achieved for your content to be WCAG-conforming on a certain level. You can refer to success criteria to test your site's accessibility.

You can't cheat your way around following Success Criteria by saying things like, "it's WCAG conforming if we just ignore this part of the page" - conformance is defined for full web pages only. If a web page is one of a series of web pages presenting a process, the whole process needs to conform to WCAG at the specified level. You also can't claim conformance if users aren't able to use your site with accessibility tools (such as screen readers): you should implement WCAG in a way that user agents and assistive technologies understand your site and allow users to use it properly.

The success criteria require that something be done in the Web content that would make it possible for assistive technologies to successfully present the content's information to the user. For example, a picture you were supposed to click on to go to a topic would not be accessible to a person who was blind unless text alternatives for the picture were provided in a way that user agents, including assistive technologies, could find and display them. The key here is that the text alternative must be included in a way that user agents including assistive technologies can understand and use - in a way that is "Accessibility Supported."

(Understanding Accessibility Support)

If you have trouble understanding a particular success criterion, aren't sure how to implement it, want examples of (non-)compliance, or need clarification in any way, you should refer to the following: * Understanding WCAG 2.1, a supporting document by the WAI providing a guide to understanding and using WCAG 2.1, providing "non-normative extended commentary on each guideline and each success criterion" * Techniques for WCAG 2.1, a supporting document providing guidance to developers and evaluators on meeting WCAG 2.1 success criteria * How to Meet WCAG (Quick Reference), a tool that provides a customizable and filterable view of WCAG resources, including the standard itself, Sufficient Techniques, Advisory Techniques, and Failures (as implementation guidance), and Understanding WCAG (as supporting information)

The How to Meet WCAG (Quick Reference) is probably the go-to way to refer to WCAG and its accompanying documents we've just discussed, as it presents content in a straightforward, searchable, and filterable manner.

Other resources

WCAG is an in-depth standard covering accessibility requirements. While Techniques and Understanding WCAG provide technical implementation examples and approaches, they mostly cover implementation details. They might not cover some useful real-world practices when building accessible web solutions.

Many useful resources cover these topics on the web, and it's useful to take a look at them. We'd suggest considering them as extending WCAG, not replacing it.

A note on ARIA

We'll be mentioning ARIA a lot throughout the Web Accessibility Handbook - so, what's ARIA, now?

ARIA, or WAI-ARIA, stands for (Web Accessibility Initiative) Accessible Rich Internet Applications. It's a set of attributes that allow the user agent to better present data about the web page and its content to the operating system's accessibility APIs, making the site more friendly to assistive technologies.

ARIA provides a framework for identifying user interaction features, their relationships, and states; marking regions and structures on the Web; and includes technologies to map controls, regions, and events to accessibility APIs.

WAI-ARIA is a standard published by the ARIA Working Group, part of the W3C's Web Accessibility Initiative. Find out more about WAI-ARIA on w3.org

Look at the section "ARIA and building accessible websites" for more information about ARIA.