Accessibility supported technologies

Use web content technologies in ways that are accessibility supported and work with the assistive technologies that people use.

Meeting the Web Accessibility Standard

When the following requirements are met, this satisfies WCAG Conformance Requirement 4:

  • only accessibility supported ways of using web technologies are relied upon to ensure content meets WCAG success criteria
  • any information or functionality that’s provided in a way that’s not accessibility supported is also available in a way that is accessibility supported.

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.

For more about WCAG conformance, see Understanding Conformance — WCAG 2 — W3C.

What are web content technologies?

Web content technologies are things like the languages and different file formats that authors use to create web content that can be understood by user agents and presented to users.

The 3 core web content technologies are:

Other examples of web content technologies are:

What is ‘accessibility support’?

Accessibility support is about making sure that web content is implemented in ways that work with the user agents, including assistive technologies (AT), that people use. It defines how web content technologies can be used to meet WCAG 2 Success Criteria.

For a detailed explanation, see Understanding Accessibility Support — WCAG 2 — W3C.

For more on how web content is consumed and presented by user agents and AT, see the Knowledge Area: Browsers, code and assistive technologies.

What does ‘accessibility supported’ mean?

‘Accessibility supported’ refers to a web content technology:

  1. that is used in a way that works with the AT and the accessibility features of browsers, operating systems, and other user agents that people use
  2. for which there are user agents and AT that people have access to and can use. This means that at least one of the following is true:
    • The technology is supported in common user agents or plug-ins, such as browser add-ons or extensions, that work with the AT that people use.
    • The technology is used in a closed environment, such as a government office, where the user agents available support the technology and work with the AT that people use.
    • The technology is supported in one or more user agents that work with the AT that people use, and are as costly and as easy to procure for a disabled person as for a non-disabled person.

For further explanation, see What does accessibility supported mean? — TPGi.

Use accessibility supported technologies

When producing web content:

  1. Use web content technologies in ways that are supported by the browsers, AT and operating systems that your audience commonly uses.
  2. Use web content technologies according to their WCAG 2 Techniques for meeting specific WCAG 2 Success Criteria.
  3. Avoid using web content technologies in ways that replicate WCAG 2 Common Failures.
  4. If the content is implemented using web content technologies in ways that are not accessibility supported, provide an equivalent version of the content that uses technologies in accessibility supported ways and that can be accessed despite the non-accessibility-supported use of technologies.

What is or is not accessibility supported?

WCAG defines what constitutes accessibility support, but it does not specify which technologies can be considered accessibility supported in any given situation.

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

For more, see Documenting Accessibility Support for Uses of a Web Technology — WCAG 2 — W3C.

The amount of testing and documentation that’s needed to create and maintain a comprehensive repository of accessibility support information is even greater. Understandably, the breadth and currency of accessibility support information that’s available is often limited. Keep this in mind when reviewing test results from the following resources:

Browsers, AT and operating systems: 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. Government organisations also have internal websites, such as intranets and document management systems, that only employees can access.

Where the site owner does not have control over the browsers, AT and operating systems being used by those visiting the site, it must be assumed that people will be using the site with all sorts of browsers, AT and operating systems. This means that the website will need to be developed using web content 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 an organisation’s intranet, the specific browsers, AT and operating systems available to users can be constrained. In this case, web content technologies only need to be accessibility supported by those specific browsers, AT and operating systems.

Use WCAG 2 Techniques

One way to help ensure accessibility support is to use web content technologies in ways described by the Techniques for WCAG 2. These cover multiple ways of using standard web content technologies like HTML, CSS and JavaScript to meet specific WCAG 2 Success Criteria.

For full details, see Techniques for WCAG 2 — W3C.

Note: Not all Techniques for WCAG 2 provide accessibility support.

For example, the Techniques include ways of using PDF. In the context of New Zealand Government public facing websites, however, where the range of users’ browsers, AT and operating systems cannot be controlled, PDF is not considered accessibility supported technology, and cannot be relied on to deliver an accessible experience. See PDF and Word not accessibility supported.

Avoid Common Failures

The Techniques for WCAG 2 include Common Failures, which define ways of using web technologies that will result in a lack of conformance with particular WCAG 2 Success Criteria. Get familiar with these Common Failures and make sure not to replicate them.

For more, see Common Failures — Techniques for WCAG 2 — W3C.

PDF and Word not accessibility supported

PDF and Microsoft Word cannot be relied on as accessibility supported web content technologies. HTML remains the format to use for accessible web content that meets the New Zealand Government Web Accessibility Standard. If content is published as a PDF or Word document, the same content must also be published in accessible HTML.

PDF and Word documents viewed in a web browser are not entirely accessible to screen reader users. This is the case in all common operating systems, but especially macOS, iOS, Linux and Android.

For instance, Success Criterion (SC) 1.3.1 Info and Relationships requires that information, structure, and relationships conveyed through presentation are also conveyed programmatically for AT. However, in macOS and iOS, the VoiceOver screen reader, which otherwise provides reliable accessibility support for core web technologies like HTML, CSS and JavaScript, does not communicate to users all the semantic structure that PDF and Word documents contain and convey visually. The same goes for Word and PDF documents with the TalkBack screen reader in Android. In these scenarios, it is not possible for a Word or PDF document to meet SC 1.3.1, as the technology (MS Word) is not accessibility supported in this manner by VoiceOver.

Similarly, WCAG 2 Success Criterion 1.4.10 Reflow requires that content be viewable at an effective page width of 320px without requiring horizontal scrolling. But PDF and Word documents viewed in a web browser do not support reflow—that is, they do not rearrange their content into a single column so that users who zoom in can still see or access all of the content without having to scroll left and right. So Word and PDF documents are not accessibility supported for reflow and cannot meet SC 1.4.10.

For best practices on creating PDF and Word documents, see the Web Content Type: PDF and office documents.