What are the Web Content Accessibility Guidelines (WCAG) and are they being followed?

The Web Content Accessibility Guidelines (WCAG), first published in 1999, are on paper a well-researched set of guardrails to make the internet more accessible and inclusive. Primarily aimed at those with disabilities, they also benefit all users and have been instrumental in enforcing universal design standards that keep the web usable across different devices.

Dig a little deeper, however, and you find a set of powerful accessibility tools that are underimplemented, underdiscussed, and regularly misunderstood. They are part of a patchwork of accessibility tools that inundate the modern web. In some parts of the world, including the US, they are seen as a pseudo-legal framework.

The WCAG, now on version 2.2, sets out a set of ratings: A, AA, and AAA, and what it takes to accomplish that designation and are created by the World Wide Web Consortium’s Web Accessibility Initiative. These range from contrast ratios, to keyboard accessibility, to screen reader compatibility. WCAG constitutes one of the main tools used by digital accessibility advocates and disability-focused IT workers but critics point out they’ve also been used to sell products.

Tools such as accessibility overlays have routinely taken advantage of companies worried about being sued. Some overlay companies have even been fined by the Federal Trade Commission (FTC) for false advertising.

Eric Portis, a developer experience engineer at Cloudinary, believes that the current landscape means that there are more and more accessibility-aligned developers but that resources haven’t always kept pace.

“The amount of people who care has grown and grown,” he says.

“It's not just the people writing the books and people writing the guidelines. Now it's many front end developers, but I do feel like some of that care takes the shape of being really frustrated at the systems that they're within and that they don't get priority or budget always, to be able to implement or learn about these things.”

While accessibility is a common conference topic for example, that doesn’t always translate to real world change. Data when it comes to accessible websites can be difficult to quantify. For one, a website may ‘fail’ a section of the WCAG guidelines simply because the site does not have that particular element. Broad industry reports also tend to be looking for big numbers over a large swathe of the internet when the reality of accessibility is that it is hyper specific to each individual user.

Britne Jenke, founder of Inclusive Pixelation, sees part of the issue with how WCAG guidelines are implemented as being rooted in a narrow view of how they can be used.

“I'd say in the business world, people don't think it applies to them because they may not be making a website or something technical, and WCAG can really have some broad applications to e-learning, to documents, to the platforms that we use to deliver these things to our learners.”

She says another challenge – especially when it comes to how disability-related information is shared with teams from management – is identifying whose job it is to implement frameworks like WCAG.

“It gets muddled, I think, in some of the other language that we use, it gets grouped under different topics. It might be, ‘Oh, that's not my responsibility. That's the DEI team's responsibility,’ or, ‘That's not mine, that the web developer's responsibility.’ In this disability space, we maybe have a shift of… pushing off that responsibility onto someone else sometimes, not always, a loud or large amount of voices speaking up to say, ‘Hey, I can do this. I can make accessibility changes in my own personal work.”

Implementing WCAG as a business

There’s a joke in disability advocacy spaces, told many different ways, that there are only two reasons institutions give for not implementing accessibility: it’s too expensive or we don’t have time.

Sanjay Sarathy, vice president at Cloudinary, thinks that there are multiple pressures on companies that mean accessibility isn’t always the focus. For one, the push and pull of the way business have traditionally been run, especially in start-up land.

“I think part of it is historically, at least with product and engineering teams, you're driven by: what do we think the market needs? What do we think our customers need?... And if that's [accessibility’s] not necessarily an explicit part of what customers are asking for, you may not always be thinking about it.”

For that to change, he believes that accessibility has to be foundational or, to use his metaphor, like “table stakes.” When asked what an indicator for his company would be in terms of showing that accessibility has been more fully integrated into his company’s knowledge base, Sarathy said it’s a multi-faceted answer.

“Being able to provide advice. Not just, ‘Oh, here's the product, don't worry, here are the guidelines,’ but actually be in a reasonable position to provide advice when our customers ask us questions about WCAG compatibility. That, to me, would indicate that not just are [we] embedding it, but we're knowledgeable enough to be able to talk about it intelligently with our customers. And I think that's a journey for us.”

For Jenke, implementation can look a little more grassroots.

“If you can't convince your leadership to spend a lot of time on accessibility, just find ways to start working it into your own workflow. Whether that's creating some good templates for yourself with good heading structure, good color palettes that match for colour contrast. Just see what you can do personally without getting approval from above if that's where your roadblock is.