Accessibility and Access Keys

Skip to Content

How to make PDFs WCAG2.0 compliant

13th July 2011 by Liam McGee

A recent email about PDFs from Wayne Dick, W3C working-group buddy, got me thinking about WCAG2.0, PDFs and whether W3C missed a trick in not pushing hard enough for a formal separation of styling (look and feel) from content (text, and informational relationships between text (such as headings)).

The W3C has always been somewhat hamstrung when it comes to offering guidance on making particular proprietary technologies accessible because of their (very sensible and understandable) restrictions around vendor neutrality. We at Communis would certainly support a e-publishing-specific set of best practice (a bit like the mobile web best practice), which could cover PDF, as well as e-book formats such as ePub (the latter especially, as it has the advantage of being free, open source and quite well supported by hardware vendors), and perhaps we’ll prod the working group about it.

But onto Wayne’s specific point about PDF, namely, that a PDF can claim WCAG2.0 compliance while still being inaccessible to Low-Vision users. Wayne’s point was that you can’t set your own user preferences for font face, colour, and so on. this is really important for many low vision users. As Wayne says:

The most important barriers for visual readers with low vision are typographic. The visual style preferences of people with full sight shut readers with low vision out of reading most text. Font sizes, visually confusing font faces like Times New Roman, kerning, single spaced lines and disorienting color schemes like the standard black print on white background are just a few factors of presentation that combine to impair perception of text.

The difficult problem is that each visual reader with low vision experiences a different combination of typographic factors as barriers to reading. Some prefer normal font size. Others need large font. Some require high contrast. Others need low contrast. Low vision is not just one disability; it is a cluster of disabilities. The typographic solution for this group is to give each person a custom choice of typography, a typographic prescription.

The thing is, there is a separation of style from content, at least in the underlying code (assuming that the PDF is produced with accessibility in mind – so far, so much like web pages). The ability to change the font is part of the PDF technology, it’s just that the Adobe Reader tools to make use of that are a bit ropey. Reader already allows the user to set a default foreground/background colour scheme (Edit>Preferences>Accessibility – Replace Document Colors). So all that is left is the ability to change the font face… If you have Adobe Acrobat, for example, rather than plain ol’ Reader, the Tools>Advanced Editing>TouchUp Text Tool allows you to change the font face (and style) and fill colour of selected text. A hook into this capability would be technically feasible (LiveCycle, for example, turned on bits of Acrobat in Reader), one that would allow wholesale edits to font face/style (e.g. replace all fonts with verdana).

So… PDF content, could cheerfully comply with WCAG2.0 1.3.1 (Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.), and 1.4.8 (Foreground and background colors can be selected by the user).

All we need now is for someone to fund us to develop it. Anyone?

Comments are closed.