Introduction to WCAG

From enterprise tech companies to fast-food companies, accessibility is on the menu. And why shouldn't it be? The "information superhighway" promised a veritable superhighway of information. Those companies, and most companies in between, have noticed that it's good for users and/or good for business to have that information accessible to as many people as possible. Like the diagram below shows, there can be permanent, temporary, and situational reasons for people to need accessibility accommodations.

Unfortunately, dedicated accessibility developer positions within these companies have not always kept up the pace. This means that we frontend and full-stack developers, skilled in HTML, CSS, JavaScript, and/or JS frameworks, might find ourselves in uncharted territory when asked to "make the website accessible." What are we to do?

Some developers may be tempted to throw code at the problem to see what works - with the help of accessibility tools.* Accessibility testing tools like Axe and Wave provide great results. However, like any failed test, we have to know how to change our code in order to make the test pass. A testing tool might present us with five ways our code is faulty:

Which one is the culprit? Or do we need to fix all of these?

WCAG

The answers we seek lie in WCAG. Here is the Web Content Accessibility Guidelines (WCAG) quick reference, which is like the {insert your favorite reference to an important book or trophy here} of accessibility. It's not necessary to memorize every guideline, but knowing how to read a guideline, its success criteria, and its techniques will be a great start towards "making the website accessible."

WCAG is composed of four layers of guidance: principles, guidelines, success criteria, and sufficient & advisory techniques. Let’s look at each layer.

Principles

The top layer contains four accessibility principles:

1. perceivable
2. operable
3. understandable
4. robust

The guidelines and success criteria are organized within these principles for clarity.

Guidelines

The next layer contains the 13 guidelines. These serve as goals for authors to work toward to make content more accessible. They are not testable, but help authors understand success criteria better.

Let's take a look at a specific guideline to learn how to dissect any guideline that crosses our path in the future. The example we'll look at is Guideline 3.3 - Input Assistance. In the image below, the relevant hierarchy is:
  3. Understandable - Principle
    3.3 Input Assistance - Guideline

Success Criteria

Digging deeper into our example, we reach success criteria. As mentioned, guidelines are helpful for understanding accessibility goals, but success criteria are testable so that it can be clearly shown if conformance has been met.

In the menu structure above, the relevant hierarchy is:
  3. Understandable - Principle
    3.3 Input Assistance - Guideline
      3.3.1 Error Identification - Success Criteria

Error Identification success criteria is met "If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text." Ah, now this we can test!

Clicking the button to the right will provide even more information about this guideline (the quick reference on the previous page is meant to be a quick reference!).

It's worth reading a few of these in depth, as they are a wealth of information.

An aside: the 13 guidelines are each broken into many success criteria, which can make it seem like there is a lot to keep track of. It can be helpful to focus on the guidelines and understand the high-level goals. Here it is "help users avoid and correct mistakes." From a UX perspective, this is something that - without any talk of accessibility - can be incorporated into development from the very beginning. Accessibility need not be complicated.

Sufficient and Advisory Techniques

The final layer contains sufficient techniques, advisory techniques, and documented failures. Sufficient techniques are provided by the working group as reliable ways to meet the success criteria. Advisory techniques may work, but may not be stable or testable. Documented failures show authors what to avoid or items that fail specific success criteria.

This success criteria has both sufficient and advisory criteria, but not all guidelines will.

Summing it Up

Though memorizing every guideline and success criteria in WCAG is not necessary, being able to dissect a success criteria when it comes onto your radar is an invaluable skill for any web developer to have. Whether an accessibility tool like Axe or Wave flags it for you or you get assigned a ticket with a cryptic number in it, the skills you learned above will serve as a map to navigating WCAG "making the website accessible."

I'm not advocating we **not* use tools like Axe and Wave. Exactly the opposite. They are indispensable and belong in any web development accessibility workflow. However, they should be used alongside at least a high-level understanding of WCAG and the skills to dig into any WCAG guideline when needed.