PDF accessibility improving, not easy

When Adobe Systems Inc. announced early in 2001 that its Acrobat 5.0 would make Portable Document Format files more accessible to people with disabilities, many government Webmasters breathed a sigh of relief.

Much of the information on most government Web sites is contained in PDF files, and until recently, they were not at all accessible to visually impaired users.

When I was asked to research how to create accessible PDF files for a PDF-heavy site I was reviewing, the first thing I did was attend a free training session on creating accessible PDF documents. This session was hosted by Highway 1, a training organization for the federal government, and led by an Adobe representative. During the training session, the Adobe representative demonstrated how to use Microsoft Corp.'s Office 2000 products to easily create accessible PDF files. He stressed that we should use styles, rather then simple formatting, because styles directly convert to tags when changed to PDF files. He also showed how to use the tags editor and make accessible plug-ins to create accessible PDFs from documents that were not created in MS Office 2000. He even manipulated a scanned document so that it became accessible to screen readers.

He admitted, however, that Adobe still had a way to go, especially with creating accessible tables and forms. He speculated that Adobe would come out with plug-ins for those elements in August, and that revisions to the Adobe 5.0 version of the software would most likely have included them.

I was eager to return to work to try out the magic I saw him perform. I had my notes and the "How to Create Accessible PDF Files" booklet in hand. Acrobat 5.0 and the make-accessible plug-in were installed on my computer. I was ready.

The first obstacle I encountered was my office's MS Office software. We used Office 97, not 2000, so it was not going to be quite as easy as I thought. With Word 2000, you could incorporate the "alt tags" and structural markup in the Word document before converting it to PDF.

Using Word 97, the alt tags would have to be added after the conversion. However, I was still optimistic that I could make accessible PDF documents in a reasonably short time.

I was able to convert a Word 97 document into PDF using Adobe Acrobat 5.0, and then run the accessibility check feature built into Adobe Acrobat 5.0. The check reported several problems, including missing language specifications and a lack of structure.

By following the directions in the booklet and in my notes, I ran the make-accessible plug-in on the newly created PDF. That added structural mark-up where it belonged. Then I ran the accessibility check once more. It passed.

Finally, I cranked up the screen-reading software (JAWS, by Henter-Joyce) and listened for my PDF to be read. I heard the path to the file name read. Then silence. I tried it again, no luck. I re-booted. Again, no luck.

Finally, for assistance, I turned to an e-mail list for users of JAWS software, and discovered that I needed the latest version of JAWS to read PDF files. I downloaded the latest version of JAWS from the Henter-Joyce site site and once again tried to hear my PDF file. Success!

Now I was ready for a tougher test. I downloaded an existing PDF file from the Web site I was reviewing and ran the accessibility check. This time the software seemed to time out and returned an error message that contained information about symbols.

I could not find anything about this error message in the Adobe Acrobat 5.0 help pages, nor could I find it on the Adobe Web site. All I could find was some reference to Korean and Japanese fonts. I knew we didn't use Asian fonts on this file, so I was baffled. I eventually discovered that the accessibility checker could insert comments into the PDF where the problems lie, and learned the trouble was with the list bullets that were used in the document.

After talking to the author of this PDF file, I discovered that a type of desktop-publishing software created the source document, and the list bullets were symbols and not actual list bullets. The author also informed me that she never used MS Office products, but used WordPerfect instead. So the easy accessibility option was no longer a choice.

Another obstacle was the fact that, while images can be given alt tags using Adobe 5.0, there seemed to be a character limit to the alt tag. (Although this was refuted by an Adobe spokesperson.) As a rule, an alt tag should not be a long explanation, but a brief description of the image. HTML has its D-link and longdesc; there does not seem to be anything comparable in PDF files. Most of the PDF files on the site I was reviewing had important images, such as graphs and charts, where an alt tag would not suffice.

In the end, the clients of the Web site I was reviewing decided to have the documents also be available in HTML format, and not pursue the accessibility of PDF files until the bugs were worked out of Adobe Acrobat 5.0.

All in all, Adobe makes some great products, and its attention to accessibility is to be commended. With the most recent versions MS Office products and Adobe Acrobat, one can create a relatively accessible PDF document that can be read with the most recent version of two screen readers.

The lesson I learned was that nothing is ever as easy as it seems, especially when one or two factors are different from what at first seemed easy. The fact that PDF files and accessibility are the topic of some discussion on accessibility e-mail lists proves that even the experts don't have all the answers.

Patrick is an expert in Web site quality control and accessibility at Caliber Associates, Fairfax, Va. Her e-mail address is donapatrick@yahoo.com.