MS Word not an accessible alternative

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.

5 comments

  1. Comment #1. Sarah:

    Thanks for this, Jason.

    Just for clarity: does ‘MS Word’ docs refer to RTFs in this situation?

  2. Comment #2. Jason Kiss

    Hi Sarah,

    By ‘MS Word document’ we were referring in particular to DOC or DOCX files. RTF is a proprietary Microsoft format, but it is even more limited in the kind of data it can hold and does not provide much in terms of structural semantics. To that degree, the situation is much the same: Unless the document’s content is nothing but straightforward paragraphs of plain text, RTF cannot be considered an accessibility supported format.

  3. Comment #3. Sarah:

    Thanks Jason.

  4. Comment #4. Wendy:

    Hi Jason, I understood that if you provided an html version of a PDF document (the PDF being given as a link on that same html page), and the html version met the web requirements, the PDF did not need to. Has this now changed, in that the PDF must also meet all the requirements (eg colour contrast)? I can’t find clear answer to this, but maybe I’m missing it. thanks

  5. Comment #5. Jason Kiss

    Hi Wendy,

    In the context of the NZ Government Web Accessibility Standard, PDF is not currently considered an accessibility supported technology. It therefore cannot be relied on and PDF documents need to be accompanied by accessible alternative versions in a format like HTML. As such, the PDFs you currently publish do not need to conform to the Web Standards.

    That said, for many users, a PDF can be a perfectly accessible technology, depending on the content and layout of the PDF, how it was structured and produced, and the software or technologies a user has at their disposal. For that reason, we recommend that, where possible, efforts are made to produce otherwise accessible PDFs that conform to WCAG 2.0. See the PDF Techniques for WCAG 2.0 that the W3C has published.

    Hope this helps.

Navigate Posts