WCAG isn’t just for websites

This post isn’t specifically about how to apply the ‘Web Content Accessibility Guidelines’, or WCAG, or my phonetic pronunciation of ‘wick-ag’. Instead, this is about how the WCAG aren’t just for websites, and the guidance available to support what we’ve said all along.

As a quick intro, WCAG 1.0 was created in 1999 by experts from the World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI). While it has been added to over the years, the basics have remained the same. More checkpoints have been added, and one has been retired as web technology has changed.

Jump forward 25 years and WCAG is still generally accepted as the go-to globally agreed set of accessibility digital guidelines. But remember, they were originally created to address WEB accessibility when the Internet was in it’s infancy. The title reflects that origin.

I was working in this field about the time WCAG 1.0 came out and for a very long time I’ve maintained that WCAG guidelines aren’t just for websites. As a company we use the WCAG principles for all types of digital reviews. But the original terminology seems to be a sticking point for some who want to know why we use WEB guidelines when testing software interfaces.

I remember one software developer telling me that my talk was very interesting but was too web focused, just because I mentioned the WCAG principles. We didn’t discuss websites, we were focused on the software his company was creating. We discussed the principles of perceivable, operable, understandable and robust which apply to all digital interfaces not just web. But the WEB in WCAG was tricky for them.

Once people get past the acronym, it is great to help clients see that colour contrast, for example, is just as relevant on software, apps, kiosks, ATMs as it is on websites. Or that native mobile apps still need to be fully keyboard accessible because many assistive tech users use external keyboards on their phones.

With a little bit of help from the experts at W3C WAI, we can also point people to another set of guidelines that show how the WCAG can also be applied to software and other technologies like cash machines, ticket systems, and museum displays.

“Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)” provides clear guidance about how to make all digital information accessible, not just websites.

What I love is that many of these guidelines state… “This [checkpoint] applies directly as written [in WCAG], and as described in [the WCAG success criteria].” Yes there are some that differ slightly in their application, and there are some that include notes.

In general these notes follow the WCAG 2 principles, guidelines, and success criteria, showing how they can be applied to non-web Information and Communications Technologies (ICT), specifically to non-web documents and software.

This guidance is informative only, and isn’t mandatory but offers fantastic advice for making non-web documents and software accessible.

At the time of writing, the current version only covers WCAG 2.0, but the draft version of WCAG2ICT covers all WCAG 2.2 Level A and AA success criteria, conformance comments, and new key terms. Once ratified this will bring the guidelines up to the latest web accessibility standards. It is still in draft, and W3C WAI is looking for feedback.

If you are interested check out the current guidance and be part of the update by providing your feedback.

But the key take home message is that, despite its name, WCAG goes far beyond just the web. I wonder if W3C WAI will consider changing it to Digital Accessibility Guidelines…That would be a DAG.