Accessibility supported technologies

The Web Content Accessbility Guidelines (WCAG) 2.0 that form the main requirement of the New Zealand Government Web Accessibility Standard come with five conformance requirements. The fourth of these is that [o]nly accessibility-supported ways of using technologies are relied upon… to meet the WCAG 2.0 success criteria.

Accessibility support

The concept of accessibility support is complex, but central to the application of WCAG 2.0. Accessibility support defines how features of web technologies (e.g. HTML, JavaScript, PDF, Flash, etc.) can be used to meet the WCAG 2.0 success criteria. At the same time, what is considered an accessibility supported use of a technology depends on the context of use, that is, what browsers and assistive technologies site visitors use, and how well they support the specific use of the web technology.

A way of using a technology is accessibility supported if it is supported by users’ assistive technologies as well as the accessibility features in browsers and other user agents.

To qualify as an accessibility-supported use of a Web content technology (or feature of a technology), both 1 and 2 must be satisfied for a Web content technology (or feature):

  1. The way that the Web content technology is used must be supported by users’ assistive technology (AT). This means that the way that the technology is used has been tested for interoperability with users’ assistive technology in the human language(s) of the content,

    AND

  2. The Web content technology must have accessibility-supported user agents that are available to users. This means that at least one of the following four statements is true:
    1. The technology is supported natively in widely-distributed user agents that are also accessibility supported (such as HTML and CSS);

      OR

    2. The technology is supported in a widely-distributed plug-in that is also accessibility supported;

      OR

    3. The content is available in a closed environment, such as a university or corporate network, where the user agent required by the technology and used by the organization is also accessibility supported;

      OR

    4. The user agent(s) that support the technology are accessibility supported and are available for download or purchase in a way that:
      • does not cost a person with a disability any more than a person without a disability and
      • is as easy to find and obtain for a person with a disability as it is for a person without disabilities.
Understanding WCAG 2.0. Copyright © 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved.

For more information, see the Understanding Accessibility Support section from Understanding WCAG 2.0.

Accessibility support in the NZ Government context

Open versus closed environments

The audience for most New Zealand Government websites is the general public. With some websites, the audience might be a more specific subset of the general public, e.g. registered members of a special working group. Unless the site owner has control of the browsers and assistive technologies being used by the people accessing the site, it needs to be assumed that people will be using the site with all sorts of browsers, assistive technologies, and operating systems. This means that the website will need be developed using technologies in ways that are accessibility supported by a broad range of user agents.

Where the site owner does have control of the environment in which people will be using the website, e.g. a department’s intranet, the specific browsers and assistive technologies available to users can be constrained. In this case, it is easier to use web technologies in ways that target the accessibility support of those known browsers and assistive technologies.

What is or isn’t accessibility supported?

Determining if a particular use of technology is accessibility supported can be tricky. As noted in Understanding WCAG 2.0, [i]ndividual authors will not usually be able to do all of the testing necessary to determine which ways of using which Web technologies are actually supported by which versions of assistive technologies and user agents.

Using WCAG 2.0 sufficient techniques

One way to address this is to confine your uses of web technologies to those for which WCAG 2.0 sufficient techniques have been published. These techniques cover multiple ways of using standard web technologies (e.g. HTML, CSS, JavaScript) to meet specific WCAG 2.0 success criteria.

The Techniques for WCAG 2.0 document also covers a wide range of common failures that describe ways of using web technologies that will result in a lack of conformance with particular WCAG 2.0 success criteria. Web authors should ensure that they use web technologies in ways that do not replicate these common failures.

Not all sufficient techniques provide accessibility support

The WCAG 2.0 sufficient techniques include ways of using specific technologies that currently cannot be considered accessibility supported in the context of the typical New Zealand Government website. In particular, and for the time being, these include the sufficient techniques for PDF, Flash, and Silverlight. See below for more details.

PDF, Word, Flash, and Silverlight

For most New Zealand Government websites where the range of users’ operating systems and user agents can’t be controlled, specific ways of using some technologies cannot be relied upon. Common ways of using these technologies are not accessibility supported in the user agents that a site’s visitors can be reasonably expected to be using.

Specifically, unless a Government organisation has control over its users’ operating system and assistive technologies, all but the very simplest uses of PDF, Microsoft Word, Flash, and Silverlight cannot be relied upon to meet a variety of basic WCAG 2.0 success criteria. This is because these technologies have variable, and in some cases, very limited accessibility support on the Mac OS and Linux platforms for screen reader users.

For instance, in Mac OS, the VoiceOver screen reader, which otherwise provides robust accessibility support for most ways of using core web technologies like HTML, CSS, and JavaScript, does not communicate to its users the semantic structure that otherwise accessible Word documents or tagged PDFs contain. VoiceOver can read Word documents and PDFs, but does not identify any structure. As a result, unless the PDF contains nothing but straightforward, unstructured text, e.g. no heading, no lists, no tables, it cannot be relied upon to deliver accessibility support, and so an accessible alternative, e.g. an HTML version, of the same content must be provided.

The situation is very similar on the Linux platform, as it is with technologies such as Flash and Silverlight.

As the accessibility support for these technologies improves, it should become permissable to rely on them for the delivery of web content in the context of most New Zealand Government websites.