Firstly, apologies for such a long delay between posts – especially on a topic that garnered such interest!
This is part two of a review of the Accessibility Support Documentation for PDF. Reading through the document is quite reassuring, with every single success criterion (even the AAA ones) either supported by Adobe, or the responsibility of the document author.
It’s only when one reads the Appendices that it becomes apparent that all is not as it seems. Adobe PDF does fail in some serious ways, it just seems to have escaped the author of the Accessibility Support document.
But firstly, I looked at the lack of testing, and make sure you read the comments because there is one from Adobe!
Secondly, let’s look at the document in more detail.
Correctly tagged headings
In response to WCAG2 Success Criterion 1.3.1: Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text, (Level A). Adobe says:
“PDF provides a variety of ways to convey information and relationships with semantic elements such as headings, lists, tables, and paragraphs. The ISO 32000-1 PDF Specification details structure types in section 14.8.4.
- Test id 4 (Correctly tagged paragraphs)
- Test id 5 (Correctly tagged headings)
- Test id 6 (Correctly tagged controls and input elements)”
However, if one actually reads Test id 4, 5 and 6 in the Appendices, it actually turns out that Window Eyes does not read headings. In fact, if you don’t believe me, read the Appendices, and I quote:
“Headings are identified. (WE [Window Eyes] does not identify headers but does read text)”
Headings are extremely important to screen reader users. It allows them to scan a document to determine which section they need to read. And this is especially important in PDF documents, because PDF documents tend to be much longer than your average web page – that’s a lot of text to trawl through if you can’t jump from heading to heading.
You know, headings are so important that they are mentioned at WCAG2 Level A twice. Success Criterion 2.4.1: Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages, also requires headings, so that screen reader users can jump from one place to another. Adobe says:
“PDF allows documents to be tagged with headings which can be used in conjunction with assistive technologies to bypass sections of content. PDF also provides bookmarking functionality that allows keyboard users to accomplish similar bypassing.
- Test id 9 (Correctly tagged headings)
- Test id 10 (PDF bookmarks)”
Once again, if one reads test id 9 and 10 in the Appendices, it turns out that Window Eyes does not read headings, but it does read bookmarks. So, instead of using headings to break up your PDF you could use bookmarks, but then a review of the Appendices shows that JAWS doesn’t read bookmarks. Now this is a real problem. It means you need to markup every heading in your PDF twice: once as a heading (so JAWS will read it), and once as a bookmark (so WindowEyes will read it). And remember, I talked about the scarcity of testing previously, so there could be assistive technology out there that reads neither.
A few more accessibility concerns…
- The abbreviation feature is not supported by the magnifier ZoomText.
- You can embed media, but there is no equivalent of the HTML NOEMBED feature. This means users cannot set an alternative for any media they embed in the PDF.
- You can only adjust the primary background colour of the PDF – not the background colour of regions of a page.
PDF is not an accessible technology… yet. I do commend Adobe for being one of the first companies to address accessibility issues in their products, however they still have a long way to go to match the accessibility features of X/HTML. The difficulty in tagging a PDF also essentially prohibits accessible PDFs from being developed in the mainstream media.