Why document accessibility and PDF/UA matters

  • Author: Tim Lohman
  • Date: 20 Mar 2014

Media Access Australia's Access iQ spoke to Shannon Kelly, Global Accessibility Solutions Subject Matter Expert at Actuate, about document accessibility and the PDF/UA standard, ahead of her presentation at the International Technology & Persons with Disabilities Conference.

Access iQ (AiQ): What is PDF/UA and why is it important?

Shannon Kelly (SK): PDF/UA is an ISO (International Standards Organisation) standard (14289-1) for the Portable Document Format (PDF) aimed at making PDFs universally accessible (UA). It is a technical standard at the code level giving requirements for how you implement code for PDF readers like Adobe Acrobat, PDF writers like Word, as well as assistive technologies like JAWS. What PDF/UA is not, is a set of best practices. What ends up happening a lot of times is that, if a content author outputs their content to the PDF/UA format; they think that it is automatically converted into an accessible document. That is not true. Matt May from Adobe did a blog on this last summer and he said that the PDF/UA format isn’t the source of accessibility problems, which was true.

AiQ: What were the challenges with accessible documents that led to PDF/UA’s creation?

SK: The biggest challenge was that there were no clear standards for the conversion of native source documents into accessible, tagged PDFs. People may have thought that by clicking a button in Microsoft Word or Adobe InDesign to convert to PDF with an automatic tagging process, that they were creating an accessible PDF. However, unless the native source document was created with accessibility in mind and the document, once converted to PDF, then had the tag structure retouched and manipulated by an editing tool such as Adobe Acrobat Professional, the result was generally a tagged, but poorly navigable or usable document to a blind or visually impaired person using an assistive device such as a screen reader.   Without a  set of technical requirements that address the content (such as from a Word document) being converted, the reader will access the content (such as Adobe Reader) and the compatibility with assistive technologies like screen readers, the result was typically very inconsistent PDF output of auto-tagged documents often with illogical semantics and mark-up. That really resulted in a lack of usability by the screen readers’ users. So what you had was the proliferation of poorly accessible or completely inaccessible PDFs on the web.  The case with inaccessible and poorly accessible documents is that, not only do they not serve the community of the blind and visually impaired, but they also do not serve the needs of the general population in the way we have become accustom to accessing data via text search, copy and paste functions, etc.

AiQ: You said earlier that even with the PDF/UA standard that there are still accessibility issues. Are there techniques people can use to avoid these?

SK:  Absolutely. When creating a Word document, ensure that you design the document with accessibility in mind. As an example, the document author would utilise the Table function in Word to create a table, or using the List function to create a list, as opposed to using only tabs and character symbols to create an ad hoc table or list. You can also make sure to define the text using the style formatter for both headings and body, because a heading format in word will translate to a specific heading tag in the PDF/UA. A list properly using the List format in Word will also translate to the proper list tags in PDF/UA. For non-text elements, such as images, you should be certain to provide alternative text descriptions with those images in your Word document. Additionally, you’ll want to use a standard font that conforms to accessibility guidelines such as Arial, Times New Roman, Tahoma, Helvetica or Calibri and also be certain to populate the document properties, as well. 

AiQ: Beyond being the right thing to do, are there other reasons businesses and government agencies should be actively producing accessible documents?

SK: Yes, because it is the right thing to do, and government agencies and businesses in many countries are required to conform to regulations, legislation, and accessibility standards for their web and web content including their PDF documents.  Today these organisations are pushing the customers toward self-service via the web — governments, telecommunications, healthcare, utilities, insurance providers and banks, for example. That means that access to those kinds of services and e-delivered communications like bills, statements, notices, healthcare information, and banking and financial statements must be made accessible to everyone. There are guidelines, such as the Web Content Accessibility Guidelines (WCAG) 2.0, which provides a globally accepted and adopted set of guidelines for accessibility regarding web and web content. Those standards have been adopted now in 17 countries and they offer organisations very specific techniques for making their content — including all PDF documents — available in an accessible and usable fashion.  

I’d also point out that, even with the increased use of HTML, the PDF standard is not going away. It will remain the vehicle for organisations to present their data online. The PDF format in some industries is the required archive format to preserve the original document of record.  Additionally, most all major financial and insurance organisations have sophisticated enterprise technology that converts into PDF formats massive amounts of data from millions and millions of customers into their statements every month – the larger challenge with accessibility here is the sheer volume, repetition and scale of this PDFs. The PDF format is critical in moving toward universal accessibility.

AiQ: What barriers exist today in making documents more accessible?    

SK: Formerly, the only way to make a document accessible was to design it with accessibility in mind, convert it to a PDF format and then open it in an application like Adobe Acrobat Pro and manually tweak those accessibility tags. So the challenge is that this a time-consuming process for an organisation’s one-to-many documents – things like annual reports, marketing collateral etc. But for businesses and government agencies, how can you do that for thousands, millions or tens of millions of documents – such as bills and statements — that you have to e-deliver in PDF form every month? We would argue that you need an automated enterprise-level technology solution like the Actuate PDF Accessibility Solution, which allows these organisations to easily produce accessible documents in high volumes which meet WCAG 2.0 level AA compliance. The advent of the PDF/UA format has enabled the development of this patented new technology that is truly a “game-changer” in the world of high volume, e-delivered customer communication PDFs.

Shannon Kelly is Global Accessibility Solutions Subject Matter Expert at Actuate, a Silicon Valley-based global software provider with offices in Sydney, and the makers of the Actuate PDF Accessibility Solution. Actuate will be presenting on PDF/UA and PDF Document Accessibility Risk, Regulation, and Solutions for Compliance at the International Technology & Persons With Disabilities Conference, March 17 to March 22, 2014, Manchester Grand Hyatt Hotel, San Diego, California, U.S.A. Shannon’s presentation is available for download (PDF 1.35mb).

Want to learn more about WCAG 2.0 and web accessibility?

The Professional Certificate in Web Accessibility, a university-accredited online qualification jointly conducted by W3C member Media Access Australia and the University of South Australia, is a fully assessed six-week program that covers both accessibility principles and techniques. The course provides students with all the essentials needed to achieve compliance with international best practice in accessibility.

Accessible documents, among many other aspects of WCAG are covered in Access iQ’s complete guides to web accessibility for content authorsweb developers and web designers