Even though WCAG 2.0 isn’t designed to be used beyond web content, its technology agnostic nature and foundation in user needs means that we can use it as a tool for assessing iPhone/iPad apps, desktop apps and more.
WCAG 2.0 was designed to be technology agnostic. Contrast WCAG 2.0 with WCAG 1.0 and you’ll see that version 1.0 specifically references HTML and nothing else. WCAG 2.0 takes a more modern approach, allowing you some freedom of choice in terms of technology. Think of it this way — if the technology has accessibility support, and you use it appropriately with that support, you can meet the requirements of WCAG 2.0.
This fits very well with the way that I’ve always tried to approach accessibility:
I don’t care what technology you use, as long as you use the accessibility features of that technology properly.
I know it isn’t quite that simple, and I generally advocate using HTML-based solutions over others, but in reality, at the end of the day, if you can support accessibility with what you build with Technology X, then do it.
I was very very happy to see that the W3C recently published an update to the Techniques for meeting WCAG 2.0 that included a huge number of Flash specific techniques for WCAG 2.0. Even if I don’t always agree with the choice to use Flash, that isn’t my battle. My battle is making sure that if and when you do choose Flash, you implement accessibility. People are going to continue to use Flash and they need to have the tools and techniques to ensure they are creating accessible content.
What about non-web content?
I’ve seen and heard this a few times in the last while — someone will post a message to a mailing list asking “We’re building an application for iPad/iPhone. Is anyone else doing that with a focus on accessibility and if so, are you following WCAG 2.0?”
People inevitably point to Apple’s Accessibility Programming Guide for iOS to provide guidance for making accessible iPhone apps. That is excellent advice — it is comprehensive and has a lot of valuable information.
Other responses flatly dismiss WCAG 2.0 for this scenario — “WCAG 2.0 is meant for web content only.”
My take? Just because something isn’t web content, per se, doesn’t mean that we can’t still take the core principles of WCAG 2.0 and apply it to an iPhone app. WCAG 2.0 is based on user needs. Your content and functionality, whether part of an app or delivered via browser, needs to be:
Nothing precludes you from using WCAG 2.0 as a framework for assessing an iPhone app. Your app’s functionality and content needs to be perceivable, operable, understandable and robust, doesn’t it?
The implementation details are different than with HTML. Even so, we’ve used WCAG 2.0 as a framework for assessing iPhone apps, Flex/Flash applications, and even Java and other desktop apps as part of our accessibility consulting.
Even if it isn’t “web content” per se, core user needs remain.
Have you used WCAG 2.0 as a framework for other types of content? I know all the guidelines don’t necessarily apply in a non-web context, but what other challenges did you run in to? If so, we’d love to hear about it… please do share!