The growth in the use of mobile devices and the cloud and native apps that run on them has exploded in recent years—led by tablet devices and smartphones in particular.
The rate of growth is so fast that global consultancy Deloitte expects that about one billion people will transition from ‘dumb’ phones to smartphones during 2015 alone.
However, while the rate of mobile device usage has soared off the back of falling prices, improved features and the increased speed and availability of mobile data, the international web standards required to make mobile devices and the apps that run on them accessible has lagged behind.
This has meant that software developers, device manufacturers and the multitude of different businesses that now offer their services through apps are somewhat stuck. They may want to do the right thing and the smart business thing—make their apps accessible to as many people as possible, including people with a disability—but they have lacked the guidance on how to do this.
Can’t I just use WCAG 2.0?
In seeking a solution to mobile application accessibility it has been suggested to simply just use the whole of the World Wide Web Consortium’s (W3C) Web Content Accessibility Guidelines (WCAG) 2.0, but this approach is problematic, as is detailed in this excellent blog post on accessible software and apps by Ken Nakata.
Nakata argues, in essence, that the problem is that some aspects of WCAG 2.0 perfectly apply to software, but then some really don’t. The result, he says, is that that “While applying WCAG 2.0 to software gives the illusion of being an easy and effective solution, I believe it creates pushback and confusion in the IT community, takes focus away from more appropriate alternatives, and ultimately hurts users with disabilities.”
But—and it’s an important ‘but’—while you can’t just ‘copy and paste’ WCAG straight across to mobile apps, WCAG is still useful in the way it’s informed the WCAG2ICT guidelines. (We’ll come back to WCAG2ICT shortly.)
WCAG and beyond
To return to WCAG 2.0 for a minute, we should point out that the shortcomings of these guidelines for mobile accessibility have been recognised by the W3C, which in February 2015 released draft guidance on mobile accessibility.
The guidance acknowledges that the mobile device/apps space remains in flux, and that dedicated mobile standards are yet to be drafted, so is best viewed as something of an emerging best practice guide.
In effect the draft guidance is a blend of elements from its evolving standards—User Agent Accessibility Guidelines (UAAG), Authoring Tool Accessibility Guidelines (ATAG), and Independent User Interface (Indie UI)—with elements from its established guidelines—Web Content Accessibility Guidelines (WCAG) and Accessible Rich Internet Applications (WAI-ARIA).
Indie UI and UAAG are a problem, though
While the draft guidance is an improvement on using WCAG alone, there are issues with the combined standards approach too, W3C member and Media Access Australia’s resident web accessibility expert Dr Scott Hollier says.
Dr Hollier says that Indie UI is not directly applicable because it is more about the development of a consistent command set using multiple interfaces.
“While this is likely to be helpful to mobile Operating System (OS) developers in making sure the ‘swipe’ command corresponds to the equivalent keyboard command, and app developers may find this information useful in making sure their app behaves consistently using different user interfaces across different platforms, it’s not directly relevant to whether or not assistive technologies will work with an app,” he says. “Indie UI is also still in development and in all likelihood will take some time before it is polished enough to have an impact.”
Dr Hollier says UAAG also has some issues, such as the fact that it is chiefly related to the accessibility of user agents of web content such as web browsers and media players.
“While extremely relevant to the developers of mobile operating systems in ensuring that their web browsers work effectively, it’s not relevant to this project as the app is native rather than web content,” he says. “Even if the app were web-based, UAAG is still more targeted at developers of web browsers rather than web content.”
WCAG2ICT for the win
As such, Dr Hollier says that until dedicated mobile accessibility standards emerge, W3C’s WCAG2ICT guidelines, which seek to apply accessibility principles specifically to software (as well as non-web documents) are a better bet.
“WCAG2ICT is applicable to the challenge of mobile accessibility for a number of reasons, not least of which because it is specifically created to explain how WCAG 2.0 can be applied to non-web Information and Communications Technologies (ICT), specifically to non-web software,” he says.
The guidelines also stem from WCAG 2.0, the definitive web and ISO (40500) standard, so people can trust in its guidance and relevance as effective and relevant advice, Dr Hollier says.
“WCAG2ICT effectively explains which parts of WCAG are relevant to software, which apply to some degree and which do not apply at all, creating a good basis for a checklist approach in app testing,” he says.
“While WCAG2ICT is not a specific W3C standard, and there is certainly a need for a specific standard that pulls together all the W3C work going on in this space, its advice provides confidence that, when combined with user testing, key accessibility issues will be addressed based on its information.”
Guidance on WCAG2ICT
With this in mind, WCAG2ICT is a great place to begin applying current mobile accessibility best practice.
But organisations looking for additional guidance should contact Media Access Australia—Australia’s only independent not-for-profit organisation devoted to increasing access to media for people with a disability.