WCAG 2.0 Should Not Be Applied to Software and Mobile Apps
I have growing concerns about the application of the W3C Web Content Accessibility Guidelines (WCAG) 2.0 to software and particularly mobile apps.
To avoid any confusion, let me clarify that when I say “software and mobile apps,” I am not talking about software with a browser-based user interface (e.g. Microsoft Office 365 Web apps, SharePoint, or Google Docs)—instead, I am referring to software that has a user interface (UI) separate from the browser. Software that runs through a browser is a “Web based application” and is squarely in the ambit of WCAG 2.0. Instead, this article is about traditional desktop and mobile software that doesn’t require browser software like Internet Explorer, Safari, Chrome, etc. My concern is that applying WCAG to this kind of software is dangerous. While at first it may seem like an easy way to achieve accessibility, I believe it actually hurts the disability movement and undermines accessibility. Also, attorneys working in this area need to be very clear about the differences between concepts like “web based applications” and “mobile apps” in their settlement agreements because this area is so ripe with confusion. Hopefully, this blog post will explain this confusion and why that confusion is so dangerous.
WCAG 2.0 was designed for Web pages and Web based applications. It was never intended to apply to software. While many of the UI concepts might appear logical for software, a more careful analysis reveals that this is not the case. A better alternative is to borrow a handful of the WCAG 2.0 A and AA requirements that make sense for software and to otherwise keep our focus on using the accessibility APIs that are a much more natural fit for achieving software accessibility. This is the approach taken in the new European accessibility standards, EN 301-549. Looking to this standard instead of WCAG 2.0 is easier for developers, improves accessibility, and ultimately leads to a more promising future for users with disabilities.
A Brief History of the Application of WCAG to Software
The idea of applying WCAG 2.0 to software started years ago when WCAG 2.0 was initially created and as software engineers noticed that many of the WCAG 2.0 accessibility concepts might be generalized and applied to software. In December 2011, this idea picked up momentum when the Access Board included the following provision in its draft Section 508 standards.
E207.1 General. Where components of ICT are platforms or applications and transmit information or have a user interface, those components shall conform to E207 and the applicable provisions of Chapter 5.
E207.2 WCAG Conformance. User interface components and content of platforms and applications shall conform to Level A and Level AA Success Criteria and Conformance Requirements specified for web pages in WCAG 2.0 (incorporated by reference in Chapter 1).
Advisory E207.2 WCAG Conformance. WCAG is written to be technology neutral. While oriented towards web pages which are defined as being delivered using HTTP, it is straightforward to apply the WCAG 2.0 Success Criteria and Conformance Requirements to user interface components and content of platforms and applications(emphasis added).
A little over three months after the release of this draft rule, I testified before the Access Board at the CSUN conference in March 2012 expressing my concerns about applying WCAG 2.0 to software. The new momentum around this idea also spurred the creation of a new WCAG2ICT Task Force within the W3C that produced a WCAG to software conformance document. The basic conclusion of the Task Force was that only a subset of WCAG 2.0 could be applied directly to software. Instead, much of WCAG had to be remolded to meet the needs of the inherent differences between software and the Web.
For some time, the idea of applying WCAG 2.0 to software remained relatively dormant. Then, in March 2014, the National Federation of the Blind (NFB) and my former colleagues at the Justice Department entered into a landmark consent decree with HR Block. I blogged about this consent decree earlier this year. Part of that settlement agreement required HR Block to make its mobile app conform to WCAG 2.0 A/AA. Naturally enough, consent decrees involving the Justice Department are highly influential and, according to some of my industry colleagues, they are facing increasing pressure to make their mobile apps conform to WCAG 2.0 A and AA. Even more recently, on November 17, the Justice Department announced a similar settlement agreement with Peapod—an online grocery delivery service in the Washington, DC area and several other major Midwest and east coast markets.
I would like to revisit the same concerns I had in March 2012 in light of these and other recent developments. I think this is particularly important now because of the added stimulus that the HR Block settlement agreement created. 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. Since originally writing this post, I have talked with both disability rights advocates and my former colleagues at the Department of Justice and have some guidance for moving forward.
Why We Need Clear Standards
I’m a big proponent of having clear accessibility standards. Here, I’m not talking about truly innovative ways for achieving the next higher level of accessibility. Instead, I’m talking about the bare minimum standards that we want to hold all software developers to. If innovative solutions represent the ceiling of our achievements, basic accessibility standards represent the floor. I believe that, at this baseline level of accessibility, we need standards that are as clear and simple as possible.
A brief review of the WCAG2ICT Task Force conformance document indicates that, in many instances, the application of WCAG 2.0 A and AA to software is not immediately straightforward. I think it is probably easiest to illustrate this with three examples.
- Success criteria 1.3.2 (meaningful sequence)
In some cases, WCAG 2.0 requirements carry over perfectly to software. For instance, the language of success criteria 1.3.2 (meaningful sequence) reads if taken directly from a software accessibility specification.
When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.
- Success criteria 2.1.1 (keyboard)
Other WCAG 2.0 requirements make sense to certain types of software, but not to others. For instance, one of the most fundamental level A requirements in WCAG 2.0 is success criteria 2.1.1 (keyboard), which requires:
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints.
This success criteria makes perfect sense for web pages, because web pages are intended to be accessed by a myriad of different types of devices, including computers with keyboards. But applying this success criteria to touch-based software on tablets or mobile devices does not make sense because the mobile operating systems may provide accessibility completely without a keyboard. For instance, applications on iOS (e.g. iPhone, iPad, etc.) can use VoiceOver built into the iOS operating system to make onscreen content very accessible to users with disabilities even if the application itself cannot use a keyboard. The WCAG2ICT Task Force report may or may not take this into consideration as touch-based devices like an iPhone might be considered a device with “closed functionality”—in which case, keyboard accessibility would not be required under Appendix A of the report. But this is very gray territory. Lawyers should not force the task of making sense of these gray areas on developers. Instead, a more software-appropriate set of standards should be chosen from the outset.
The WCAG2ICT conformance document clarifies this success criteria by noting that, “this does not imply that software must directly support a keyboard or “keyboard interface.” Without this additional guidance, iOS developers would be required to add keyboard support to an already fully-accessible touch-based mobile app. This unnecessary redundancy creates pushback in the IT community, weakens the WCAG 2.0 standards, and fails to serve the needs of users with disabilities.
- Success criteria 2.4.5 (multiple ways)
Still other WCAG 2.0 requirements make little sense in the context of software—forcing developers to come up with creative (and controversial) interpretations of how these requirements should apply. For instance, success criteria 2.4.5 (multiple ways) requires that:
More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.
The WCAG2ICT Task Force reworked this requirement to read:
More than one way is available to locate a software program within a set of software programs except where the software program is the result of, or a step in, a process.
This straightforward rewording makes sense linguistically, but fails logically. First, the ability to switch between two or more software programs isn’t within the control of the software developer—it is controlled by the developer of the operating system. For instance, on my PC, my ability to switch between QuickTime (my video player developed by Apple) and Chrome (my browser developed by Google) isn’t something that either Apple or Google can control—instead, it is in the hands of Microsoft, which developed the operating system (Windows) that my PC is running. To get around this OS limitation, the WCAG2ICT Task Force document talks about “a set of programs” in Section 2.5. In an attempt to offer clarification, the Task Force document adds, an “example of a set of software programs would be a group of programs that can be launched and used separately but are distributed together and all have a menu that allows users to launch, or switch to, each of the other programs in the group.” The only problem is that I do not know of a single instance of such a software program in the real world.
A bigger problem is that this rewording simply doesn’t make any sense in the context of software. Web sites are frequently informational with a complex structure. This is one reason why good web designers often include features like bread crumbs and site maps to help users avoid getting lost in a website. The closest analogy to this example in the world of software would be complex software with a highly nested set of menus and dialog boxes. Unfortunately, this interpretation of success criteria 2.4.5 (which might occur to a developer just as it occurred to me) isn’t captured in the WCAG2ICT Task Force document. This demonstrates that there are multiple ways of interpreting how to apply success criteria 2.4.5 to software, which only creates confusion in the IT community. This confusion isn’t a criticism of the Task Force—instead, it is a criticism of trying to carry over WCAG 2.0 as a whole to software without first giving serious thought to what is being accomplished in the process.
Even Worse With Mobile
Mobile apps have become a larger focus for the application of WCAG 2.0, particularly after the HR Block consent decree. I believe that, because the Justice Department was a party to this litigation, the consent decree has been broadly interpreted as a message that applying WCAG 2.0 to mobile apps is easy to do and that the Justice Department would be expecting it. I foresee two large problems in focusing attention here:
- Accessibility for mobile apps is already relatively new and complicated. As I will discuss below, software accessibility generally focuses on the API (application programming interface) — a concept that doesn’t exist in Web technologies. These APIs are highly specific to the hardware and user interface (UI) for the device. For instance, some mobile devices use a touch screen and no keyboard (e.g. iPhone) while others use a physical keyboard and no touchscreen (e.g. older Blackberry units). How one achieves optimal accessibility across both of these platforms is naturally very different.
- The second problem is that many mobile apps leverage Web content outside a browser—in these cases, looking to WCAG 2.0 alone may actually undermine accessibility. In a nutshell, WCAG is about what happens between a web page and the browser—it says nothing about software that isn’t the actual browser on these mobile devices. So a mobile app might appear to just be a “shell” for a browser, but that doesn’t mean that that app provides the same level of accessibility support as the actual browser on the device. It may look like the browser, but it isn’t the browser. Instead, it’s just another piece of software. On a more technical level, mobile software platforms allow developers to import classes and instantiate components like windows, dialog boxes, or even rudimentary browser windows to be built into the mobile apps—but that doesn’t mean that a browser window is actually the browser. For instance, I was working with a science center in the Midwest this summer that had its own iOS and Android apps that provided basic information about the science center via Web pages specifically written for being accessed only by these apps. Unfortunately, these browser components are not the full browser available on these mobile platforms—whether they support the WCAG 2.0 accessibility techniques to the same extent as the full mobile browser is unclear at best. By focusing attention only on WCAG 2.0 instead of the mobile accessibility API, it is entirely possible that mobile app developers may be lowering their level of accessibility. For instance, the science center’s mobile app that I just mentioned may have a form that a user can complete and submit. That form might be included in a browser window inside the mobile app. If the science center’s developers were told to build the app to WCAG 2.0, they would naturally insert <LABEL> tags into the pages accessed by the mobile app. That may work perfectly well inside the mobile device’s browser, but it isn’t clear if the relatively primitive browser component built into the mobile app would be able to leverage <LABEL> tags. Of course, whether it works or not would depend on the mobile OS and software platform and is completely outside the control of the mobile app developer. If the browser component wasn’t robust enough to handle <LABEL> tags, the mobile app would be inaccessible. This result would be particularly unfortunate if the mobile app OS’s had an API that made forms with labels accessible outside of the browser component. In this case, the developer would have likely avoided using a browser component in the mobile app and used a straightforward form component that would have been much simpler to make accessible via the mobile OS accessibility API.
Bye Bye APIs
By implementing an accessibility API, mobile developers can take advantage of the specific accessibility features built into those devices and operating systems. For instance, instead of building in a complicated speech-output program into the software, a developer on some mobile platforms can simply enter a few lines of code and leverage the speech output engine built into the mobile operating system. Voilà, the mobile app suddenly can talk! These API’s, however, are constantly evolving and highly specific to the device in use. Forcing mobile app developers to use WCAG 2.0 for accessibility effectively tells developers that accessibility APIs are not important and can be ignored.
Accessibility APIs are not limited to just mobile devices, of course. Microsoft Windows, for instance, has offered Microsoft Active Accessibility (MSAA) since 1997 and User Interface Automation (UIA) since 2005. In terms of accessibility, UIA is a particularly powerful accessibility solution. It gives very robust access and control to just about anything a user can perceive or interact with. Plus, as the name suggests, it permits a much higher level of automated accessibility testing than is currently available with just about any other technology—and infinitely higher than WCAG 2.0 (which is far less-specific with respect to articulating exact accessibility techniques). This makes it much easier to build and thoroughly test applications for accessibility.
Most importantly, however, APIs provide a perfect meeting point between software and assistive technology (AT). There is a reason why they are called Application Programming Interfaces after all! Software developers typically learn about interfaces in terms of a “contract”—when they implement an interface, there are certain features that developers agree to implement in very specific ways (usually through methods or functions that must take a very specific input and output). What they get in return is an agreement that these inputs and outputs will be used in very specific, agreed-upon ways. In fact, most powerful screen reader software (e.g. JAWS, Window Eyes, and NVDA) all leverage and rely on these APIs. As long as the developer upheld his end of the “contract” by properly implementing the API, the AT vendor’s product can use that API and ensure accessible output to the end user. Obviously, we shouldn’t turn our back on these exciting accessibility opportunities, but this is exactly what developers may be tempted to do by focusing only on WCAG 2.0 for accessibility.
Best of Both Worlds
There is a better approach to software accessibility including:
- Borrow Sensibly from WCAG 2.0. There are some WCAG 2.0 requirements that make perfect sense with software. Others need to be reworked or dramatically clarified. Others still should simply be scrapped for software accessibility. Selectively borrowing from WCAG 2.0 serves to harmonize software standards with the Access Board’s draft Section 508 standards and gives developers a common set of functional UI expectations regardless of whether those UI elements appear on Web pages or in software.
- Leverage Existing APIs.We obviously don’t want to throw the baby out with the bathwater and ignore existing accessibility APIs.
It just so happens that this kind of hybrid standard already exists. Earlier this year, the European Telecommunications Standards Institute (ETSI), which serves as an official standards setting body for the European Union (EU) announced the release of EN 301-549 as the official accessibility standards for public sector IT procurements by EU member states. A copy of these standards is available at the ETSI website.
Ever since the original Section 508 standards came out in 2000, there has been a strong pressure to harmonize the world’s IT accessibility standards. Thus, after the U.S. Access Board released its draft Section 508 refresh in 2011, the EU was under strong pressure to harmonize with these standards. Accordingly, the software standards refer heavily to WCAG 2.0, but EN 301-549 made very deliberate efforts to adopt very selectively from WCAG 2.0 A and AA. For instance, that troubling example of success criteria 2.4.5 (multiple ways) is removed from EN 301-549’s software standards (on the other hand, it is kept in EN 301-549’s Web standards where it logically belongs). In my other example of success criteria 2.1.1 (keyboard access ), EN 301-549 outdoes the WCAG2ICT Task Force by limiting the success criteria’s application to software only where the software specifically supports access to keyboards or a keyboard interface—thus avoiding any confusion for mobile apps that rely entirely on touchscreens. In other words, EN 301-549 borrows sensibly from WCAG 2.0.
In addition, EN 301-549 effectively requires OS and software platforms to have an accessibility API (requirements 220.127.116.11 and 18.104.22.168). It also encourages developers to support that API (requirement 22.214.171.124)—otherwise, the developer must meet a long list of other specific accessibility features—and it requires assistive technology to support the platform’s accessibility API (requirement 126.96.36.199). In other words, EN 301-549 strongly encourages the use of existing accessibility APIs.
The strong push to harmonization that I mentioned earlier now works the other way—the United States will be under enormous pressure to ensure that the final Section 508 standards harmonize with EN 301-549. In fact, if I were to wager what the next Section 508 standards look like, my guess would be that they will look an awful lot like EN 301-549.
Is there any guarantee, however, that software displaying web content will ensure that any accessibility markup in that web content will be faithfully passed to AT? This is what might potentially happen with the science center app I mentioned earlier. EN 301-549 requires compatibility and interoperability with AT. So tags and other features inserted into web content will be faithfully passed to AT running on the same device.
At first glance, one might be tempted to say that the software needs to conform to the User Agent Accessibility Guidelines (UAAG), a set of guidelines also created by the W3C for the design of software that renders web content (such as browsers). The only problem is that UAAG is still in a working draft and rumors are that there is good reason to suspect that it may never become a final document. In addition, with the exception of Microsoft, no other major browser manufacturers are members of the UAAG Working Group. I’ve also been told that no browser manufacturer supports UAAG—or intends to. Thus, UAAG is not the way to go.
I personally believe that EN 301-549 is the best accessibility specification available. It’s a remarkably well thought-out document that leverages the best of existing technologies while encouraging innovation. While it references the application of WCAG 2.0 to software, it is clearly done to facilitate harmonization with the Section 508 standards refresh and to eliminate confusion by only referencing the standards that can be clearly applied to software.
While I was at the board meeting for the International Association of Accessibility Professionals (IAAP), I discussed about this issue. One of them was from a leading advocacy group while others were part of the AT industry. I offered my views and am hopeful to slowly convert others to this position. Hopefully, a few more thoughtful discussions will start swinging the tide.
Clarifying Future Settlement Agreements
While I was attending the Accessing Higher Ground conference in Colorado earlier in November, I hunted down one of the attorneys who has been working on the mobile app settlement agreements. Apparently, the mobile apps in both the H&R Block and Peapod settlement agreements were shell applications that displayed web content. In other words, when the settlement agreements said that “mobile applications had to comply with WCAG 2.0 AA”, the intent was to say that the “web content accessed by mobile applications had to comply with WCAG 2.0 AA.”
Of course, that difference is enormous—particularly in light of the historical background that I described at the beginning of this post. To avoid the kind of problems I described in this post, I would like to propose that clauses like this one from the H&R Block settlement agreement:
“[The Defendant] shall ensure that its mobile applications conform to, at minimum, the WCAG 2.0 AA.”
Should be broken down into two different clauses:
“[The Defendant] shall ensure that mobile applications are independently accessible to and usable by persons with disabilities by ensuring that mobile applications conform to a recognized set of software accessibility standards, such as EN 301-539 section 11” and
“[The Defendant] shall ensure that web content accessed by mobile applications conform to, at minimum, the WCAG 2.0 AA.”
I suspect that this minor change would avoid a huge amount of confusion for the developer community in the future.