Use of PDF in accessible documents
The use of PDF documents can be permissible in sites that comply with WCAG+Samurai. However, certain conditions must be met.
- Ordinary documents that are newly created and that consist of text or text and graphics may not be published solely in PDF, unless they fall into one of the exceptions listed below. That means you cannot routinely publish plain-text or text-and-graphics documents solely as PDF, including press releases.
- If you provide compliant HTML versions of such documents, you may also provide PDF.
- All PDFs must be tagged, using appropriate semantics for the document. (In other words, a document in which all text is tagged as
Para does not comply if not all that text really is a paragraph.) In particular, mathematical documents must use MathML or equivalent tagging.
Note that PDF is not a “proprietary” format, meaning an unpublished format. PDF has been published online since Version 1.4 and as a printed book since Version 1.0.
You may use any version of PDF that supports tagging (i.e., Version 1.4 and later). PDFs may additionally comply with any published PDF(-derived) specification, including PDF/X, PDF/A, and PDF/UA.
The following file types may be published solely as PDF.
- Footnoted, endnoted, or sidenoted documents. (There is no defined method to mark up any of those structures in HTML.)
- An interactive form, since PDF interactivity can do more than HTML can. (Use with caution and only if HTML really is insufficient.)
- Combined accessible and inaccessible versions. A typical case is a scan of a historical document that also includes live text. Another example is a sign-language translation inside or alongside a written text or audio recording.
- Documents created solely for printing. (Documents created for printing at service bureaux can be PDFs.)
- Documents designed for annotation and round-trip travel. (If you are posting a document to elicit comments, which are then sent back to you, PDF has useful structures that HTML lacks.)
- A type specimen, if impossible or unreasonably difficult to create in HTML.
- of formats that cannot be rendered in a browser (e.g, Illustrator or Photoshop documents or other proprietary documents)
- of formats that can only be rendered unsatisfactorily in a browser (e.g., CAD drawings where GIF and JPEG do not have sufficient resolution)
- of PDF files meant as examples of PDF files (e.g., a comparison of tagged and untagged PDFs)
- A record of a document’s state at a specific moment.
- A document in a language whose script has no satisfactory support in Web browsers. Any such unsatisfactory support must be well researched beforehand. This case can also be a subset of the type-sample case if your PDF is meant as an illustration or documentation of the writing system used by a language.
- Mathematical documents, if HTML is insufficient to encode and/or render the mathematics.
- Documents with a legally restricted or legally designated format (e.g., tax forms).
- Orphan documents, where the originating software cannot be located or cannot be used on a current system.
This list may grow slightly over the forthcoming years as new edge cases are discovered. If so, this list will be updated, and version histories will be given. This list is always to be considered definitive. If you discover new PDF use cases that should be added to the list, contact us.