Problem with role mapping paragraph styles to tags, from InDesign to PDF.

[GreenRoof]

I am using InDesign 15.1.1 to create several accessible, tagged PDFs.

I have tagged every paragraph style correctly under the export tags for PDF (Edit all export tags > show: PDF), and I have left any list items and table of contents items with the default ‘Automatic’ tag.

I am exporting as an interactive PDF with ‘Create tagged PDF’ checked. 

Then when viewing the PDF in Acrobat Pro DC, in the Tags pane I have selected ‘Apply role mapping to tags’. This should ensure that in the tags pane in Acrobat, all my original paragraph style names are displaying as the tags that I have created. But this is not happening. I am finding that some of the tags are role mapping correctly, while several other tags are appearing incorrectly role-mapped with their original paragraph style names in place instead of the tags that I had assigned to them in InDesign.

There seems to be no logic to this. Why have some of my paragraph styles been role mapped correctly as per the tags I have created in InDesign and yet some styles have not? I am having to fix the role mapping, tag by tag in Acrobat which is a tortuous waste of time.

Is there a bug that can be causing this? I really need a solution as I have some very large documents to create as accessible PDFs.

[GreenRoof]

Update: this role mapping problem is occurring on every document I export as a tagged interactive PDF, no matter the size (i.e. from a small 12pp booklet to a large 125pp brochure). The first few pages of my exported document start off fine, with all the tags role mapped correctly in Acrobat, but then as the document progresses some of the tags start to break down with their tags not appearing and instead their original paragraph style names are displayed. I have tried exporting the PDF from my another Mac and I get the same result.

Today I have discovered something interesting: if I export just a few pages at a time then the role mapping is working correctly. The problem seems to occur when I export the full document – InDesign does not seem to be able to handle all the information correctly en masse.

Is this a known issue? Does anyone have a solution?

[Laubender · Accepted solution]

Hi GreenRoof,

can you see a mutual characteristic in the paragraph styles where this does not work?

Perhaps the styles are based on others or something like that.

You said:

"…if I export just a few pages at a time then the role mapping is working correctly. The problem seems to occur when I export the full document …"

Yes, this sounds very much like a bug. You can report it at InDesign UserVoice:

https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs

When done please come back here and share the URL for the report so that others can vote for fixing the issue.

Thanks,
Uwe Laubender

( ACP )

[GreenRoof]

Hi Uwe,

Thanks very much for your feedback.

I did already look for mutual characteristics, such as styles based on other styles, but there does not seem to be a common characteristic. Some of the paragraph styles which are based on other styles are role mapping correctly, while others are not, so I don't think that is the reason. The only common characteristic I can see is that the deeper you get into the brochure, i.e. where more paragraph styles come into play, the more the tags start to lose their role mapping. It is very odd, and there is no rhyme or reason to it. It is as if InDesign just cannot cope with processing the entire document properly, it just wimps out, which is pretty useless.

It is very frustrating after I've set up all the tags in InDesign to later find I need to manually fix them one-by-one in Acrobat.

Thanks for the link to user voice, I will report this as a bug. It is certainly bugging me! I will update here as per your suggestion.

[GreenRoof · Accepted solution]

Potential InDesign bug has been reported to Adobe, awaiting feedback:

https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs/suggestions/41230030-indesign-is-no...

[GreenRoof]

This has been voted as fixed, but to date the issue is not fixed. 

I did report the issue at InDesign UserVoice as a possible bug, but so far I’ve had no response from developers to that post, and no indication of the timescale for fixing it. 

In the meantime I’m still experiencing instability when exporting a tagged PDF from InDesign, with large parts of the document not role mapping correctly. I am having to workaround the problem by exporting my InDesign documents in sections and then stitch them together in Acrobat. 

Some indication that Adobe are looking into this would be reassuring. 

[bchampagne]

Helo. I am having this exact issues. My paragraph styles are all tagged. When looking in the tagged panel in PDF, all is fine, but one you go into the properties of that tag is takes on the style name and accessibility assist programs read the style name. HELP!!!

[Mystical_fighter5E2C]

I do have this problem as well every now and then. I assume that it is caused by other problems in the tagging structure, for instance broken references or the like. Often when I resolve other issues indicated by the PAC3-test, these issues with the role assignment vanish.

[Katie Kelly Designs]

I was having this issue as well!!!! I'm not sure what ended up fixing it but I did the following:

- I made sure I didn't have any skipped Headings (ie: no H1 then H3 right after it)

- I condensed my Paragraph Styles (used more character styles for bold or colour changes instead of having a paragraph style for it) and deleted the paragraph styles I wasn't using

I think the following was what fixed it:

- I went into the Tags panel and selected "Map Styles to Tags" and then I basically matched all the styles to tags (like you can in the "Edit all Export Tags" in the Paragraph Styles box.

I'm not sure why this happened, it has never happened before and I have done many accessible documents in InDesign/exported to PDF. I may have clicked "Map Tags to Styles" by mistake? I have no idea - but it's fixed now thank goodness!

[Katie Kelly Designs]

Also... I made sure that the Paragraph Styles weren't "Based on" any other styles

[GreenRoof]

Hi Katie,

Many thanks for your input. What you're saying is interesting.

I don't think having a paragraph style based on another creates any issues. But I do agree that keeping the list of paragraph styles simple does make a difference. It seems that InDesign cannot cope with a long list of paragraph styles – it can only role map the first few styles in the list and then it seems to run out of memory or get confused for the rest.

Last year I did an experiment with a complicated large document, which had a very long list of paragraph styles – I changed every para style name to a simple two- or three-word name such as Cat, Pop, XY, AB, Dog. And when I exported the interactive PDF all the styles were role-mapped correctly! Clearly it's not practical to have such ridiculous style names, so since then I have made sure I keep list of the paragraph styles shorter, simple and with names which are not similar to each other, and then use character styles more to define nuances. 

I'm interested in what you're saying about 'Map styles to tags'. I've looked at this and don't understand how to set it up. Can you advise?

[Katie Kelly Designs]

In the "tags" panel/box (where you see artifact, story, image...etc.) in the menu part (3 lines in the top righ of the box), you select "Map Styles to Tags" and this will open a box where you can match the paragraph style to the tag - just like you do in Export Tagging in Paragraph Styles. 

I have NEVER had to do this before for an accessible document but I was trying everything to fix it!

Thanks for sharing your experiment! I had named a few paragraph styles "heading" and then "heading copy" so I see how that may have confused InDesign. I thought once I Export Tagged them it wouldn't matter the style name but I guess you're right!

Like I mentioned, I did a few things at once so I'm not 100% certain which one fixed it but just relieved it is fixed!

On another note... I recently found out something about the download process of an accessible PDF from a website. Typically a website will have "Click here to download our 2020 Annual Report" or something like that. If a user clicks on that, it will take them to an online PDF viewer to view the document, from there you can save/download it and then open in acrobat or JAWS whatever the user is using to open an accessible document. Unfortunately, this way erases all accessibility features. I spoke to Adobe Help and they said "The moment you upload a PDF to a website, Adobe rules are no longer applicable, the website rules take over"

So... I spoke to a really nice gentleman at WebAim and he said to avoid that, put (PDF) after the link name. So for instance: "Click here to download our 2020 Annual Report (PDF)"

This is a hint to the user that it is a pdf and they know instead of clicking on the link, they need to:

1. right click on the link

2. "save link as" - then save it to their computer

3. open the file with whatever screen reading software they are using

This will ensure that the accessible features we put our blood, sweat and tears into (haha) will remain!

If you are posting accessible pdf's to websites you can test this by clicking on the link and have it open in the online viewer, then download/save it as a pdf from there. After that, open it in Acrobat and do an Accessibility Check, it won't pass. However if you take the steps I outlined above (right clicking on the link and "save link as") then opening it in Acrobat and checking it, it will pass. 

Just a little tidbit I learned and thought I would share!

[Bevi Chagnon - PubCom.com]

There's a lot of stuff in this thread, so I'll attempt to clear up the confusion in a series of posts.

1. Accessing and Reading PDFs from websites.

That's great advice from WebAIM; users should always download the PDF to their computers and open it in a PDF viewer that is compliant with the PDF/UA standards. This allows all technologies to process the file, whether it's an assistive technology (like a screen reader) or not.

Browsers themselves do not (at this time) have the capability to fully view and process a PDF file. They leave out many of the features, like the ability to fill out a PDF form or for assistive technologies to read the Tags tree.

Some end users have installed plug-ins inside their browsers that can give them some PDF features, but the best method is to download the PDF and open it in Adobe Acrobat, Acrobat Reader, or some other brand of full-featured PDF viewer.

And your accessibility features are NOT erased! It's just that the dumb browser doesn't recognize them.

—BJC

Member of the ISO committee for accessible PDFs.

[Bevi Chagnon - PubCom.com]

2. Role Mapping and Map Styles To Tags

These are 2 different utilities in 2 different software programs that do 2 different tasks. Here's an overview of when to use them.

Role Mapping (Acrobat Pro)

Some source programs and PDF export/conversion programs don't do a good enough job of exporting the correct tag into the PDF. InDesign is notorious for picking up the name of the paragraph style and using a bastardized version of it as the tag name — that is, a "custom tag" that is not part of the PDF tag set (the defined set of tags to specify and label different parts of a document, defined in the ISO PDF specification for PDF/UA-1).

A Tag like <Big_Blue_Title> isn't recognized by any assistive technology because it's a custom-named tag.

So Role Mapping lets us change how that tag is interpreted in Acrobat: We can set <Big_Blue_Title> to be recognized as <H1> in the Role Map utility (Tags Panel / Options menu / Edit Role Map). It doesn't actually change the tag, and the original custom named tag is still there. It's just a way to re-interpret it for assistive technologies.

In an ideal world, Adobe's converters/export utilities would give us the correct tag that we specifity in our InDesign styles. But alas, Adobe hasn't fixed much in this system in quite a few years.  You can minimize the problems by using InDesign's Paragraph Styles tools to the full extent you can.

Map Styles to Tags (Adobe InDesign)

This is a utility in InDesign's XML tool box that let's us map our paragraph styles to XML tags. (Window / Utilities / Tags (XML), and then select Map Styles to Tags from the panel's Options menu.)

It was never intended to map to PDF tags for accessibility. The release of CS 5.5 in 2011 (10 years ago) gave us dedicated tools and export utilities to go from an InDesign layout to a tagged, accessible PDF, and you should be using these tools today. There's no need today to use InDesign's Tags and Structure panels: they are obsolete for our purposes.

If you're using it, then stop! I think it's causing many of the problems discussed above.

I design, develop, diagnose, and teach accessible PDFs from InDesign nearly every day of the year (for 21 years, overseeing many of the developments in the workflow and software). Take a course in how to use InDesign's tools correctly so that you avoid these problems, minimize the amount of futzing/correcting that has to be done in Acrobat, and word faster.

My team and I created countless PDFs from InDesign and have never seen the problems described above. And our PDFs from InDesign are in very good shape, require only a few minutes of minimal correcting in Acrobat. That's because the InDesign source layout file is made correctly.

Suggestion: learn a better way to do this. Of course, I recommend my books and live-online classes at www.PubCom.com

—BJC

Member of the ISO committee for accessible PDFs.

[Katie Kelly Designs]

Just to note - 

Even if you download it from the site and open it in your own Acrobat, it won't show the accessibility features. The user MUST right click on the "download here" and select "Save link as" then save it on their computer and open it with their program like Acrobat or JAWS or whatever screen reading device they are using. So they aren't downloading the file, they are saving the link on their computer then opening it with their program. Avoiding the web browser pdf completely!

Thanks again for your help!

Katie.

[GreenRoof]

Katie – when I trained to make accessible PDFs, I was told all you need to do is ask the IT department hosting the PDF to add a .htacces file to the server – this will make sure PDFs are opened by default in Reader/Acrobat and not in a browser plug-in. It's simple job which only needs to be done once.

[Katie Kelly Designs]

Thank you! That's a great tip and I will pass that on to my client. 

Katie.

[Bevi Chagnon - PubCom.com]

3. Causes of unexpected output.

It doesn't matter how many styles you have in the InDesign layout. We have extremely complex documents with 100+ styles and they export just fine.

It doesn't matter whether your styles are based on another style, in fact, good InDesign construction requires you to do that in many situations.

It doesn't matter how you name your styles ... long or short. The export/conversion utility is looking at what you defined in the style's Export Tag settings, not the name of your style. Or not what you set in the (XML) Tags panel either, because that panel is for XML tags, not PDF accessibility tags.

Careful, don't confuse XML tags with PDF tags or HTML tags. They are all different tags sets. Some tags are similar, but many aren't. And with XML, the "X" means extensible, which is a fancy word for customizable...or "make up whatever tag you need." When I design catalogs in InDesign using in XML, I make up my own set of tags for the project and define it in something called a schema or DTD for that particular project. I can also use a pre-defined set of  tags from a namespace, such as MathML or JATS which are created to coordinate across different technologies and databases. (Ok, enough with the geekiness!)

HTML tags are a specific set of 100 (approx.) tags defined by the W3C/ISO and its international committee. 

PDF tags are a specific set of 35 tags defined by the ISO PDF/UA-1 standard and its international committee.

XML tags are whatever someone wants them to be.

I think if better construction methods were used in InDesign, you'd see these problems disappear.

—BJC

Member of the ISO committee for accessible PDFs.

[Katie Kelly Designs]

Thank you so much for the great information Bevi! Do you know why we would have experienced this problem? When exporting to PDF, our tag structure showed our paragraph style names, for instance <Subheading>  instead of tag names <H2>. And when I did a read outloud in Acrobat it didn't recognize them as headings (wouldn't take a breath after a heading, would go right into the paragraph below it).

Katie.

[Katie Kelly Designs]

By the way, I LOVE the geekiness! It's so nice to hear from other people who are in the world of accessible documents!!!!!

[GreenRoof]

Hi Bevi,

Thanks for taking the time to give such detailed responses.

Going back to the original problem – i.e. that InDesign is not always exporting all the tags correctly/it is not converting all the paragraph styles to their assigned tags – I'm not clear what reason you're giving for this. At first you seem to say that InDesign simply doesn't always get this right, and that Adobe know about the issue but haven't bothered to fix it. Then in your later post you say that you never have any problems, even with very long complex documents. 

Please tell us your secret, because I've been trained by an accessibility expert and even they do not understand what is causing this unusal problem.

[GreenRoof]

Just to add – to be absolutely clear Bevi, I do define all my Export Tags for my Paragraph Styles using 'Edit All Export Tags' and choosing the PDF tags, not EPUB/HTML tags.

You say "The export/conversion utility is looking at what you defined in the style's Export Tag settings, not the name of your style" – yes, I know this, and this is where the problem is occurring. In some of my documents, where the paragraph style names are similar, eg 'Body text' 'Body text bold' 'Body text green', InDesign willexport/convert the first name correctly eg 'Body text' converts to the <P> tag that I have assigned to it in InDesign, but for the others it doesn't export correctly to the assigned tag and instead the tags panel shows <body-text-bold> etc.

The only way I've found to fix this is to make sure the paragraph styles have quite unique names that cannot be confused. Or to export to PDF in sections. 

[Bevi Chagnon - PubCom.com]

The only way I've found to fix this is to make sure the paragraph styles have quite unique names that cannot be confused. Or to export to PDF in sections. 

By @GreenRoof

Let's see if we can get this either fixed, or identified and resolved.

I don't want you to have to spend such an enormous amount of your design time doing this workaround. You have better things to do, like design! <grin>

[Bevi Chagnon - PubCom.com]

Are you able to send me your file (or a small portion of it)?  I'd like to run forensics on it to see what's happening. If so, contact me off list in the private message area so we can arrange the file exchange (click on my name next to my avatar in the upper left).

At first you seem to say that InDesign simply doesn't always get this right, and that Adobe know about the issue but haven't bothered to fix it. Then in your later post you say that you never have any problems, even with very long complex documents. 

By @GreenRoof

Not quite what I said. Here's another take at it:

Adobe's conversion/export utility doesn't give the formal PDF accessibility tag in the PDF, and instead makes a custom-named tag based on the name of your paragraph formatting style.

However, in the PDF, those custom-named tags are Role Mapped to the correct PDF tag you specified in the style's Export Tag settings.

Convoluted, yes. But the end result is that you get the tag you want in the PDF's Tag Tree.

Please tell us your secret, because I've been trained by an accessibility expert and even they do not understand what is causing this unusal problem.

By @GreenRoof

I have no secrets. Just 21 years of working in InDesign and accessibility, and being part of Adobe's beta-testing community (yes, long before everyone else). And dozens more years before that in accessibility, WCAG standards, PDF/UA standards, and just about everything else about accessibility because I was born into a family with disabilities. I know accessibility up front and real.

I do gladly share my so-called "secrets" in my books and classes, which you're free to purchase at www.PubCom.com. Ask any my students how much I "share." And I can't recall any of them telling me about this problem. Don't recall seeing it from any of our clients, and we've reviewed and diagnosed 10s of thousands of PDFs from InDesign at my studio via our remediation services.

I'm not saying it's not happening to you, but I truly believe there's something in your file or how your file is engineered that is causing this problem. Otherwise I would most likely have seen it by this time and reported it directly to Adobe's engineering team.

[GreenRoof]

Hi Bevi,

---

Not quite what I said. Here's another take at it:

Adobe's conversion/export utility doesn't give the formal PDF accessibility tag in the PDF, and instead makes a custom-named tag based on the name of your paragraph formatting style.

However, in the PDF, those custom-named tags are Role Mapped to the correct PDF tag you specified in the style's Export Tag settings.

Convoluted, yes. But the end result is that you get the tag you want in the PDF's Tag Tree.

---

Thanks for explaining again – I understand what you mean now.

Are you able to send me your file (or a small portion of it)?  I'd like to run forensics on it to see what's happening. If so, contact me off list in the private message area so we can arrange the file exchange (click on my name next to my avatar in the upper left).

---

I would be extremely grateful if you could take a look at a couple of files I’m having problems with. I originally encountered this problem last summer, so I’ve been waiting a long time for anyone at Adobe to take an interest, alas no solutions offered to date. I will be in touch. Thanks very much.