Recently, I downloaded the conversion plugin for Word 2k7 and attempted to convert a rather lengthy document to PDF format. Much to my dismay, creating bookmarks similar to those I see used so frequently in other PDFs I’ve come across is a process that is, to say the least, disappointing from a formatting perspective – and for seemingly no reason.

I’m merely thinking “aloud” here, but what would be nice is if the Word plugin actually provided a method of allowing the user to create tiered bookmarks under sorted, expandable headings. This would make navigation of the document much more accessible to those it’s distributed to.

I also speculate it would be helpful if it allowed the user to assign a title to the bookmark that contains spaces, since Word does not seem to like allowing that normally.

Having these issues resolved would certainly satisfy my only real complaints about the Word 2k7 PDF conversion plugin.

As an aside, I’m still rather amazed that a 1-page PDF created by Word borders on 300 pages of code when opened in Word after creation.

That’s all I have to add.

I have used openoffice to create tagged pdf, and have had no problems with headings.

Hi David, sorry for taking so long to follow up on this – you are right. At least with the new version 2.4.

Open office on OSX isn’t a particularly great experience (it isn’t consistent with the rest of the system), I had been using an older version of Neo office instead.

I installed 2.4, created a new test doc rather than importing from a Word doc, and the headings, lists, and alt text all exported to PDF fine.

I’ll update the article to reflect that, thanks David.

I wanted to make you aware of the work that NetCentric Technologies (net-centric.com) has been doing in this area. We specialize in developing products that test for PDF accessibility and remediate accessibility problems in PDF documents. A couple of things may be of particular interest to you:

1) We are about to release (in January 2008) a beta version of our office add-in product (called PAW) that generates Section 508-compliant PDF’s from Word documents, including correct tagging of tables and other objects (our VP of Product Development, Ferass ElRayes, is heavily involved with PDF/UA and has co-written the chapter on tables). If you are interested in taking a look at this beta product I can put you on our beta list.

2) We have a unique product called CommonLook for Adobe Acrobat which is the currently the leading product in testing for S508 compliance and remediating PDF documents for Section 508 accessibility. Let me know if you would like to take a look at this product as well.

Happy holidays and best wishes for 2008.

Regards,
Monir ElRayes
President
NetCentric Technologies

…role mapping needs to be part of the default output from different applications…

That is definitely the key factor, if people do the right thing (i.e. use structured content) in the source application, they shouldn’t have to worry about tags or role maps.

So what’s the process of making sure that works in different apps? It’s been done with Word, and to some extent other MS office applications, but how about other applications?

It’s a responsibility that kinda falls between the PDF creator (e.g. Adobe) and the people behind the source application.

The point is that the role mapping needs to be part of the default output from different applications, not that users need to mess around with it.

If the role map is used, the discussion about tag names becomes irrelevant, so if you are looking at a PDF file and see tag names that aaa, bbb, and ccc you don’t know if this is an issue until you either check the role map to see if these tags are mapped to known roles or test with a screen reader that is known to support the roles that you believe are used.

Ultimately what matters is not the tag name, but how it works for the end user, but it is important for people who are inclined to dig into a PDF to repair it to understand what role map does.

However, the chances of Joe Public (rather than Clark) using it are pretty remote, so I think it’s valid to compare the default output of different mechanisms.

What the role map does is take the tag names (and the spec says that you can use any name you want for tags) and associate them with known and expected roles. This may not be needed for simple documents where the author accepts Heading 1 as the top style name, but if you have a long list of styles you may have different style names for headings at a particular level depending on where they exist in the document (e.g. heading 2′s in the table of contents may have style name heading2_toc and heading 2′s in the body may be heading2, but both need to be semantic elements).

If the role map is created by the app publishing the PDF, heading2 and heading2_toc are both mapped this same role and interpreted correctly by Reader.

This is also important for people with localized versions of Word – in German the heading style name may be “Überschrift 2″ and the role map is needed to handle this translation.