Web Content Accessibility Guidelines (WCAG) 2.1

The Web Content Accessibility Guidelines (WCAG) 2.1 form the basis of the New Zealand Government Web Accessibility Standard, and come with 5 conformance requirements. The 4th of these is that [o]nly accessibility-supported ways of using technologies are relied upon… to meet the WCAG 2.1 success criteria.

Conformance requirements in WCAG 2.1

New Zealand Government Web Accessibility Standard

Accessibility support

The concept of accessibility support is complex, but central to the application of WCAG 2.1.

Accessibility support defines how features of web technologies (such as HTML, CSS, JavaScript, PDF, Microsoft Word, SVG) can be used to meet the WCAG 2.1 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 technology is considered accessibility supported if it’s supported by users’ assistive technologies as well as the accessibility features in browsers and other user agents.

Assistive technologies

User agents

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, such as 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, they need to assume that people will be using the site with all sorts of browsers, assistive technologies and operating systems. This means that the website will need to 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, such as a department’s intranet, the specific browsers and assistive technologies available to users can be constrained. In this case, it can be easier to use web technologies in ways that target the accessibility support of those known browsers and assistive technologies.

What is or is not accessibility supported?

Determining if a particular use of technology is accessibility supported can be tricky. As noted in Understanding WCAG 2.1, [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.

Understanding accessibility support

Using WCAG 2.1 techniques

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

Techniques for WCAG 2.1

Common failures

WCAG 2.1 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.1 success criteria. Web authors should ensure that they use web technologies in ways that do not replicate these common failures.

WCAG 2.1 common failures

Not all techniques provide accessibility support

The WCAG 2.1 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 techniques for PDF.

PDF and Word

For most New Zealand government websites where the range of users’ operating systems and user agents cannot be controlled, specific ways of using some technologies cannot be relied upon.

For a definition of technologies that are relied upon, see:

Relied upon (technologies that are) — WCAG 2.1

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 and Microsoft Word cannot be relied upon to meet a number of basic WCAG 2.1 success criteria. This is because these technologies have variable accessibility support on the macOS, iOS, Linux and Android platforms for screen reader users.

For instance, in iOS and macOS, the VoiceOver screen reader, which otherwise provides reliable accessibility support for core web technologies like HTML, CSS and JavaScript, does not communicate to its users all the semantic structure that Word documents or tagged PDFs might include. For example, VoiceOver can read PDFs, but does not:

• identify all the structural information about the content — such as a certain sentence being the third item in a list of 7 items
• allow a MacOS user to quickly navigate from heading to heading — or to the next list, table, or graphic.

As a result, the PDF format cannot be relied on to deliver an accessibility supported experience for some screen reader users. For this reason, an accessible alternative, such as an HTML version, of the same content needs to be provided.

The situation is very similar on the Linux and Android platforms.

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