When you have a document with multiple languages and the main language isn't available in InDesign's presets, ie the document is mainly in Kirundi or Samoan and there are some English phrases, a user should be able to select 'No language' from the style's advanced options. Instead, 'No language' will export as EN and the tag in the PDF will have EN listed as the language in the tag's properties. This is problematic because the tag's language will override the document's language properties. This is a clear failure of WCAG SC 3.1.2 (language of parts).

A screen reader won't be able to read the document because the English language tag properties will override everything.

Fixing this will ensure PDFs can be accessible to people who use screen readers in languages other than InDesign's presets.

When placing an Arabic weight statement (e.g. "13g") followed by a tab and a percentage (e.g. "19%"), the weight declaration ("g" or "mg") moves to the percentage when exporting to pdf. Only when setting PDFX/1a:2001 is selected the output is correct. But this setting removes all layers and flattens transparencies so it's not very useful.
A workaround is to place a space after the tab (so on the left side since this is a right to left language).
See screen shot in attachment. On top = InDesign file, bottom = pdf created from this file using PDFX/4. The top line in the Indesign file has no space after the tab, resulting in a wrong placement of the "غ" (= Arabic "g") as marked red in the screen shot.
Sample file : https://www.dropbox.com/s/15db51rlwen8ehg/SFDA-test.indd?dl=0

Only the pages with text+jpg are exported properly.
The pages with any other image type with some transparency, i.e. psd, ai, even png, have bold text after exporting to pdf.

It's an old issue, coming back every now and then in many InDesign editions in the past. So we all should know how to deal with it, shouldn't we? Well, here is the rub. The trick with the text placed on a separate layer on the top doesn't work anymore. Nothing works, actually. It's a major bug. A reason to downgrade to the last correct version. I needed to export a very important work today and I have spent most of my day trying to work this out. I have downgraded to CS6 eventually, just to be sure that it would work. And it did, but hey! This is not the solution.

Another workaround that I know of is to print your publication to pdf instead of exporting. But still. It is a huge bug and we need you to deal with it real fast.

My InDesign opens the destination folder when exporting PDF-files. In my work I export files daily and I have to export them separately. So when I do this, after the export has completed successfully, the destination folder opens up automatically, which is very annoying. I can't seem to find any place, where I can turn this off. I can only turn it ON, if I don't export separately.

1. brand new update CC 2019


2. Create a document with more than 2 pages. Export all the pages separately.


3. That it exports the pages separately into the destination folder without having the need to watch them in that folder (I use Bridge).


4. It opens the destination folder in a new folder window.

To recreate this bug:
1) Make a new print document 8 pages long (doesn't matter if pages are facing or not) A4 or letter size (this doesn't matter either)
2) Go to the master page and somewhere on the master page, add a new text frame and within that frame, add an auto page number.
3) In a text editor, create the following file for test purposes and save it with the name "test.txt" - (cut and paste the next five lines of text):
name
Colin
David
Jose
Max
4) Return to InDesign, go to the data merge palette and select data source (the text file that was just made). Place a text placeholder on any page (this doesn't matter where)
5) From the data merge palette, go to Export to PDF, all records, and to the desktop is fine. Any PDF setting will work, use [High Quality Print] for this demo.
6) view the PDF that is generated.

WHAT SHOULD HAPPEN:
A 32pp file should be created with page numbers going from 1-8, then 1-8 again three more times.
WHAT ACTUALLY HAPPENS:
A 32pp file is created, but page numbers either stay on 1 (if facing pages was off) or go 1-2-1-2-1-2-1-2-1..... (if facing pages was on)

If you convert a table cell to a graphic cell and then make it an interactive form field, if you use the Articles panel to control the order, the form fields do not get tagged.

1.) Create a table
2.) Select a cell and choose Table > Convert to Graphic Cell
3.) Open the articles panel and drag the frame containing the table to the Articles panel to create a new article.
4.) Enable "Use for Reading order in tagged PDF" from the Articles panel menu.
5.) Export to interactive PDF with tags enabled.

Result: If you open the PDF and look in the tags pane or run the Accessibility Checker, you'll get errors that the form fields are not tagged.

Workaround: If you cut the interactive form field and paste as inline within the cell, it exports properly and is tagged. This should not be necessary and makes a lot of extra work.

Also category: Accessibility

I'm having a problem with the PDF tags when applying alt text to a group of items- a feature introduced in the most recent version of Indesign. Even though our articles panel shows separate articles, ALL of the content that comes AFTER a group tagged with alt text will have their exported tags all appear nested within that group as well, ignoring the structure set up in the Article panel. For example:

Article 1

 Group with alt tag


      item in group

      Item in group

 more content

Article 2

 Article 2 content

Will in the exported PDF appear in the tag tree as:

Article 1 span

 Figure with alt tag


      Item in group content container

      Item in group content container

      More content container

      Article 2 content container

Article 2 span

 (empty- no tags or content containers in this span)

1. CC 2017.1


2. Create an InDesign Document with correct tagging, articles, etc. Spend hours because there is no simple way doing this without expensive plugins. Our small monthly payment is used to include more important functions like Stock-Photos. Export PDF, correct some minor errors and check it with PAC. You´ll get many Content errors, because artifacts are not properly tagged. Try to solve it in Acrobat with the tags/order/...-panel. Spend more hours with vanishing objects and many other amusing bugs. Find the Preflight-Tool to tag all objects at once.


3. Correct tagging while generating the PDF.


4. Lost my mind ...
   Please overhaul the UA-PDF workflow – or at least – fix all the bugs in InDesign and Acrobat.

Adobe InDesign version: 2019 CC

We are currently trying to establish the best workflow in creating fully accessible PDF's for screen readers and I believe we have come across a bug in the communication between InDesign and Acrobat.

Quick summary:

H1 elements on multiple lines read as separate elements unless assigned manually in Acrobat
The Structure and Article order does not transfer to the PDF

To explain the issue clearly I have numbered the images in the process order.

1. Image: 1 InDesign Accessibility setup.png


2. I have setup ‘paragraph styles’ and used the correct ‘Export Tagging’ tags for each style.


3. I have added the content I want to be read in Articles and put them in the correct order


4. I have created tags and assigned all the content correctly


5. I have reordered the ‘Structure’ to be in the reading order too

Please note - the order of the ‘Structure’ and or ‘Articles’ does not transfer to Acrobat (after selecting the correct export settings.

1. Image: 2 Interactive PDF with options selected.png
   This image shows I have selected Interactive PDF and selected:
   ‘Create tagged PDF’
   ‘Use structure for Tab Order’




2. Image: 3 Initial PDF review - incorrect content order.png
   You can see the reading order does not match either the ‘Article’ or ‘Structure’ order from InDesign which I have set up.

You can also see that the elements are ‘Spans’ not H1, H2 and P tags.

1. Image: 4 Initial PDF review - Tag number ordering incorrect.png
   You can see the screen readers reading order by the numbers shown on this image which again does not match the order I set up in InDesign.




2. 5 Initial PDF review - tag h1 splitting.png
   The tag order doesn’t match the structure setup in InDesign
   Also there is another bug when reading H1 tags on multiple lines.

You can see how the H1 tag is broken by 4 lines. This has been tested and you have to swipe 4 times to listen to the full H1 header.

1. 6 Initial PDF review - tag h1 splitting - fix by order assigning.png
   In Acrobat I have then gone into the reading order and manually set the main header to a H1 tag. This then groups the text in the tag order window and fixes the issue of it being multilines.
   You can then also see the tag has changed from Span to H1.

The same thing needs to be done for the other multi layered heading tags.

I hope this is clear enough to understand.

Problem in inDesign v15. Previous versión works fine

I use huge indesign files (wen name it A) inside a indesign file(we can name it B), is cool feature that optimice our workflow. After update, everythink looks working well but when we exporte print file in PDFx1a Format we experiment problems on RGB->CMYK conversión on images os "A"file, when we export from "B" file. But it work fine if we export on the original "A" source file. Some similar issues are detected, leaving space in white or low, strange white image file as described on attach file.

Not very sure if it is related with:
https://indesign.uservoice.com/forums/601180-adobe-indesign-bugs/suggestions/38777578-indesign-white-object-exports-as-rgb-in-pdf-x-2008

Thanks