The Four Core Principles of WCAG

Over the next few weeks I am going to start publishing articles about accessibility standards geared primarily towards software developers. I will cover various types of accessibility and some of the standards that exist, but I will start with digital accessibility because it's the type of accessibility I am most immersed in. And since I am starting with digital accessibility, I think it's important to start at the very base of the base framework - the four core principles of WCAG.

Web Content Accessibility Guidelines (WCAG) are a set of technical standards developed by the World Wide Web Consortium (W3C) to make digital content accessible to people with disabilities. There are three levels to WCAG conformance and three different versions of WCAG to dive into so on the surface it is a big, technically dense monster and it's quite intimidating to dive into. But, this article is going to ignore all of that and focus on the core principles of WCAG, which date all the way back to WCAG 2.0, which was published in 2008.

Once you think through the levels and versions, the most complicated part of WCAG is figuring out how you will pronounce it. Personally, I spell out the letters because wuh-cagg and wi-cagg just don't feel right to me. However, WCAG, wuh-cagg and wi-cagg are all acceptable.

That may seem like an aside and even a bit of a joke, but it's actually a way to illustrate why I want to start at the principles instead of actual conformance. The way that I just explained how to pronounce WCAG would conform to a AAA level. In other words, accessibility is not just about contrast ratios, but when you understand the four core principles it will make sense why WCAG compliance gets so deep into the weeds that it will mandate explaining how to pronounce acronyms.

WCAG is based upon four core principles known as POUR. My mnemonic is WCAG - four - core - pour. These are important because if you have a good grasp of POUR you can usually figure out the compliant course of action from there.

WCAG Four Core Principles - Perceivable

Once you have figured out how you will pronounce WCAG, this is the most complex part of WCAG. This principle means that information and user interface components have to be perceivable to all users. This gets complex because 'perceivable' covers a lot of ground.

Perceivable covers a lot of ground because if you want to serve a diverse group of users, you will have to serve a diverse group of abilities. Consider the gamut of visual impairments. Visual impairments cover everything from being blind, to being colour blind, to having difficulties with low contrast, to having problems with smaller text sizes.

For example, let's say you are so happy after reading this article that you decide you want to build a website so register the domain gregiscool.com. On the home page, you want to write "Greg wrote a great article on the four core principles of WCAG".

First off, if you know what video game gregiscool.com references, we could likely become friends. But second, if you want to make that content accessible you'll have to think through several things. You will have to think through a foreground and a background colour. Will the text have enough contrast against the background colour? Will the colour combinations work for people with different types of colour blindness? Hold on... there are different types of colour blindness?

Once you have thought through those perception questions, you have to start thinking through all the assistive technologies people could use and how they can interact with the content you produce. Are the buttons in your app visible to screen readers? Is your menu? What happens if you use magnification?

And so while the central concept behind this principle is simple actually applying it requires a lot of knowledge, some compassion and an open mind. It's not a linear learning process and if there is ever a time when your knowledge is complete, I haven't reached that yet (and you are reading the wrong article). It is helpful to learn how to use assistive technologies, especially a screen reader to dive deeper into this principle, but you can get very far with some education. It's also important to note that this principle is relatively easy to automate. Siteimp has some accessibility scans that mostly relate to whether or not content is perceivable.

WCAG Four Core Principles - Operable

When I think through the four principles, I like to think of the first three (perceivable, operable and understandable) as different ways to express the central idea of digital accessibility. Everyone regardless of ability should be able to use digital technologies. The operable principle asks if all users can use the controls that they can perceive.

This principle is easy to understand, but if you want to specialize in this it is where you need to learn tools. You can get quite far making sure digital technologies are perceivable with some education and an accessibility scan. But to make sure that your interfaces are fully operable you really need to be as comfortable with at least one screen reader and keyboard as you are with a keyboard, mouse and monitor. There is no real way to automate this kind of testing, though you can automate testing whether operability is possible.

Earlier I wrote about how accessibility is an area where learning never ends. This for me is the principle I keep learning more and more about. As a funny and pertinent example, about a year ago I thought it could be possible to automate this type of test. Now... I think it would require most of OpenAI's data centres to even investigate how to start.

WCAG Four Core Principles - Understandable

This principle always makes me smile because it's really hard writing an article that anyone but you can understand. Even choosing a good title and good headings takes a lot of work and a lot of practice. If you dive deep enough into this principle, you'll end up reading Ernest Hemingway, John Steinbeck and Saul Bellow.

But this goes deeper than just writing an article or shooting a video. Applications have to be understandable too - the interface needs to be clear, functionality needs to be clearly labelled and well documented, yet apparent and useful even without documentation.

Point being, creating understandable content and building intuitive interfaces is very very hard. And so, I understand and relate to why projects do not fully comply with this. But there is a very good middle ground that every project can fully comply with. An application should not be less understandable to a differently abled user.

My favourite example of this one is only using colour to convey meaning. Using green and red to convey stop and go works great... until you consider that reduced sensitivity to green light is the most common form of colour blindness. The solution is that you can use colour for design purposes, but you should also have a label explaining what each control does.

This is an excellent opportunity to get back to a key component of WCAG. Digital technologies should be accessible to people with disabilities. Well, earlier on I talked about some acceptable pronunciations of WCAG because of this principle. If you did not know how to pronounce WCAG, you likely didn't consider yourself disabled because of it. And so when I talk about accessibility, I jump around between using 'people with disabilities' and 'people with different abilities'. The latter is more accurate in spirit.

WCAG Four Core Principles - Robust

It is important to understand this principle, but in practice it can mostly be outsourced to the community. Digital media must work reliably with a wide variety of assistive technology.... including assistive technology that someone built specifically for their own use. At face value, that sounds about as possible as drinking the ocean.

But in this case, we are really saved by the communities of people who use assistive technology. They demand a certain base level of functionality and for the assistive tech they use to work with the same services that everyone else works with. Because of this, the manufacturers of assistive technologies tend to stick fairly close to standards. And so when you build something, if you are aligned with the relevant standards you will likely be okay.

However, there is one key caution. I will use the web because it is the perfect example. If you are building for the web, your adherence and understanding of semantic HTML will be freakishly important if you want to build software that works across a range of assistive technology. If you are working on a custom interface, you will need Accessible Rich Internet Applications (ARIA). ARIA is one of the most powerful accessibility tools available to developers... but if you mess it up even slightly, you will mess with assistive technologies.

In other words, 'align yourself' must be taken very literally. The moment you are less than fully aligned with standards, you will start breaking parts of your interface for people who use assistive technologies.

Conclusion

We have covered the four core principles of WCAG. To review, I like to use the mnemonic WCAG - four - core - pour. And the four principles behind WCAG are perceivable, operable, understandable and robust. All of these principles point to a concept right at the core of WCAG - digital media should be accessible to everyone.

Next article, we're going to assume that you're a developer and that you've been converted to accessibility. But now you need buy-in from the stakeholders. Once you get stakeholder buy-in, you can make accessibility part of your normal development workflow. But how are you going to get your executive team to approve of accessibility work? I don't have all the answers but I will share some strategies that have worked for me in the past.