What do you get when you pull together a gathering of end users with disabilities, frustrated industry folks who spend a lot of time cleaning up PDFs for customers so that their documents are accessible, and IT professionals who focus on accessibility at various software companies? 

A standard for accessible PDFs. 

There hasn’t been a lot written about the PDF/Universal Accessibility standard (aka PDF/UA, or ISO 14289), so you might be under the impression that it’s a fairly new endeavor.  It’s not.  It’s been a work in progress for more than five years, under the auspices of AIIM where several other PDF standards are nurtured.  There have been committee reorgs, dramatic leave-takings, and lots and lots and lots of hard work. 

So what does accessibility look like in PDF?  The PDF language contains a number of constructs for the structure of any given document.  Accessibility for PDFs must then give access to these constructs in such a way that any given assistive technology, such as a screen reader or magnifier, can easily expose every element in a given document to an AT device.  There must also exist a way to edit the constructs in the event that any given authoring tool isn't pristine in writing out the constructs.  There are three basic ways that you can build accessibility into your PDF documents; all are need to build fully accessibility documents. 

First, you need to have the document structure identify all parts of the document correctly. It sounds simple, but it isn’t really.  It’s quite possible, for instance, to have a header or footer in a document that isn’t marked as an artifact when saved as PDF.  You haven’t created invalid PDF if you’ve done this from your writer, but you have created a challenge for an accessibility tool – marking the header or footer as an artifact helps the tools figure out how to handle the text.  That is, do you read a header or footer once with each page?  Do you read them once per document?  How do you allow the user to control which way the header or footer is read?  Marking the header or footer as an artifact allows the AT to either present the user with options for how the thing is read, or it allows the AT to create a fixed way of always treating the header or footer.

Second, you need to tag other elements in your document.  You need to note when text is a list or in a table.  You need to indicate whether text is the main body text of the document or whether the text is a heading that denotes and elevates the importance of some type of content.  Images need to be marked in such a way that an AT device can tell the user, “hey look, there’s a picture here”.  Charts need to be clearly identified.  Section 14.8 in the ISO 32000 standard spells out the recommended tags and how they should be used. The PDF/UA standard will make many of those “should” for tagging into “shall”. 

Third, you need to have Alternative Text on all images, or, if images should be read as part of the text flow, you need to have Actual Text on those images.  Alternate Text, sometimes called Alternative Text or shortened to Alt+Text or AltText, gives an AT the ability to describe the image to a user who either can’t see the image or who can’t understand the image.  Actual Text should be used with things like Office’s text effects – you don’t want the text that has an effect applied to be read separately from the text around it as would happen with an image.  You want a screen reader to read the text before it, the text with the effect, and then the text after it, all in a seamless fashion.

ISO 32000-1 gives authoring applications a way to do all of these things and a way for conforming readers to interpret them.  What it doesn’t do is require the use of tagging or some types of document structure.  That’s where ISO 14289 comes in.  ISO 14289 will require the use of tags, document structure, Alternate Text, and Actual Text. 

Many PDF writers, including Microsoft Word, Publisher, PowerPoint, Excel, and Visio, Adobe Acrobat, OpenOffice.org, and others give the option to save “tagged” PDF.  From any application, however, the tagging you get is only as good as the formatting you applied to the document you started with. If you want true tagged PDF, you need to take full advantage of functionality in these apps that adds formatting for headers and footers, tables, styles, automatic bulleting and numbering, and other automated formatting options.  If you create a document with none of this type of formatting, you don’t get much in the way of tagging.  But if you create smartly formatted files that use the full functionality of the authoring application, you’ll get pretty decent tagging by default.  It won’t be perfect tagging – there is no definition of “perfect tagging” that is currently agreed on.  That’s why we’re all waiting for the release of ISO14289, and why a small be dedicated group of us is working to finish up that document.

What would help us to build an even better standard?  More involvement by the disabled community and by makers of those ATs. 

To date, we’ve had good but not extensive help from the disabled community.  Because there is such a huge diversity of disabilities, it would be great to get more breadth of experience among the folks helping to write or review the standard.  Those of us who have been working on the standard have expertise in one or more disabilities, but there are only a few of us with first-hand knowledge of any disability.  As for the AT vendors, to date we’ve had no response to several calls for participation in writing the standard.  This is really their loss.  If PDF/UA gains wide acceptance, as all the current committee members will be helping to promote at the international level, then the ATs will be subject to a standard for which they provided no input.  While it is certainly the case that standards have been written and adopted in many fields without input from key partners, in my opinion, standards development is hugely benefited by the involvement of all parties who will be affected by those standards.

If you are interested in becoming involved with the development of ISO 14289 or in simply providing opinions on what you think is most important for creating accessible PDFs, you can find contact information for the committee at this link to the AIIM website.  We’re in the home stretch for the first version of the standard, but every bit of input we get helps.