Under the old New Zealand Government Web Standards 2.0 (2009–2013), any non-HTML document, e.g. a PDF, needed an accessible alternative. Exactly what other formats, other than HTML, qualified as accessible was not specified in the Standards. However, agencies were informally advised that a properly formatted Microsoft Word document could serve as an accessible alternative. With the new Web Accessibility Standard that was issued July 2013, the criteria under which technologies are deemed to be accessible have been made clearer, and the Web Standards Working Group has further defined its interpretation of "accessibility supported".
Historically, there has been very limited accessibility support for PDF and MS Word on Mac OS and Linux, although those platforms represented a small proportion of desktop user technologies. However, those limitations have only expanded with the rapid uptake of mobile technologies and popular iOS and Android platforms, which also poorly support PDF and Word. Accordingly, neither PDF nor Word can currently be considered accessibility supported technologies for the purpose of conformance with the NZ Government Web Accessibility Standard. Unfortunately, this change in advice was not sufficiently communicated to agencies.
Accessibility supported
To comply with the Web Accessibility Standard, all five conformance requirements of the W3C's Web Content Accessibility Guidelines (WCAG) 2.0 need to be met. One of those conformance requirements is that only accessibility supported ways of using technologies are relied upon. 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.
Unfortunately, both PDF and Word documents have very limited accessibility support on the Mac OS and Linux platforms for screen reader users. For instance, in Mac OS, the VoiceOver screen reader does not communicate to users the semantic structure (e.g. what's a heading, what's a table column header, etc.) that otherwise accessible Word or tagged PDF documents contain. Similar screen reader support issues with PDF and Word documents exist on mobile platforms, iOS and Android. Unless the document's content is intentionally plain text that does not require structure, neither PDF nor Word can be relied upon as a format to deliver that document in an accessibility supported manner. In that case, an accessible alternative, e.g. an HTML version, of the same content must be provided.
As the accessibility support for these technologies improves, it should become possible to rely on them as accessible formats. It may also be that new or more recent technologies will become the recommended format for portable and printable documents. For example, the Web Standards Working Group is currently monitoring EPUB3 as a possible replacement for PDF given the increasing number of tools available for converting to EPUB3 and the format's potential for improved levels of accessibility support across platforms. We will keep agencies informed as the situation develops.
What this means for agencies
For agencies that have been publishing Word documents as alternatives to PDFs or other formats, this will likely have an effect on the conformance levels of some of their websites. But the purpose of the Web Standards is not to assign compliance scores. Instead, it is to help agencies meet their obligation to deliver accessible, quality online content and services. The Web Standards are there to direct agencies' efforts in reaching that goal, to assess the current state of their websites and plan how they will reach that goal.
The state of accessibility support for Word and PDF documents should inform agencies' thinking generally about their content management and publishing strategies. It should have an effect on how they assess the risks associated with their current publishing model and outputs, and how they will manage those risks.
For instance, for legacy Word and PDF documents that are rarely viewed by the public and for which an accessible HTML version is not available, a sufficient way to manage any associated risk around non-compliance may be to provide an accessible note summarising the document's content, alongside a way for users to request an accessible version. For more popular content, the solution may be to prepare accessible versions of that content, and otherwise review your publishing workflows to avoid getting locked in to particular formats such as Word or PDF that have reduced interoperability across devices and are difficult to convert to other formats.
