1. Brief Title

Losing german äüö (Umlauts) and letters in the Structure Tree when using "Add Tags to Document" in Adobe Acrobat DC (previous operation Number ADB-3207012-T1M7) German Language Problem?

2. Steps to reproduce the issue

Export a text document with german words that contain german umlauts (äöü), e.G.: "für, können, öfter, mögen" as a PDF without tags from InDesign or Word
Open the file in Acrobat DC
Go to "Tags" and open the little menu and choose "Add Tags to Document"
After the Structure Tree was created — save and close
when you open the document again in Acrobat DC and you can take a look at the tags in the Structure Tree and see that the letters are missing in the tags. Not only the umlauts but sometimes accompanying letters aswell
Examples: "für" -> "fr"; "können" -> "knen"
Conclusion: blind people can't read these anymore and the document is not accessible anymore!

The problem doesn't exist in Acrobat X and Acrobat XI.
The problem occurs with any font and all operating systems.
The problem was already documented with video and example-documents with the operation Number ADB-3207012-T1M7.

3. Operating system

The error occurs in all operating systems.

4. Expected results

Loss free texts in the Structure Tree with umlauts and all other letters so that the docment can be read by screen-readers.

5. Observed result

Missing letters in the Structure Tree after using "Add tags to Document" mainly in combination with Umlauts äöü and umlaut-ligatures.

Create 508 compliant PDF documents frequently that need to be passed. These documents more than not have several lengthy tables. These documents also come from different people using different software and versions. And more than not these tables need to be rebuilt. Would love to have the option to create tables in the Tags sidebar from scratch where you can at the same time specify how many TR, TH, and TD and in a certain order. Right now I can only add them one at a time. Also, if there is a way to remove the hard setup of tables. Sometimes there is only one error where a TD is split into two when it should only be one. When I combined the cells, I then get a Regularity error even though the table is setup perfectly like a grid. In this case, I have to completely rebuild the table from scratch to remove the error. Hope in the next few updates, Adobe can add some more of these options for Accessibility tables.
Thank you.

Feature Requests / Bug Reports for the Accessibility features in Adobe Acrobat Pro DC.

Adobe Acrobat Pro DC (Version 2018.011.20063) on Windows 7 Professional.

For the Tags panel:
1. Option to create Lists <L> tags with a set number of List Items <LI> tags instead of one at a time. Time wasted creating one at time.
2. Option to created tables <Tables> tags with a set number of Rows <TR> tags instead of one at a time. Time wasted creating one at time.
3. Stop forcing all the Tags folders to all be opened when opening a PDF file! Not efficient if having to reopen a PDF with an extensive Tags structure. These folders need to remain as they were when last saved!

For the Reading Order Popup menu:
1. Button to create List Items <LI> and List Body <LBody> for selected text. Currently have to manually change the tag for example <P> to <LBody>. Action Wizard is hit and miss with Lists, so I create from scratch many times.
2. Button to create Links <Link> for selected text and/or images with a popup box for enter the URL while simultaneously creating its Annotation in the Content panel and in the Tags panel. This would save time.
2. The Background/Artifact button doesn't work as it should. Items still go to the Tags panel.

For the Content panel:
1. Within the Page contents, the option to delete Annotations by selecting it and/or with a right click. This would save time.

For Adobe Acrobat Pro DC software updates:
1. Need a way to save my current customized layout so that when the software is updated, it is not lost. Time consuming to recreate with every software update. (iOS and PC).

Thank you,
terri@fusiononline.com

Why doesn't Adobe set the default initial view magnification setting to "fit page" so a viewer can see an entire document upon initial view? As a seasoned graphic designer, I believe it is much more courteous to allow the viewer to orient themselves to an entire document and then allow then to zoom in for more detail. It is disconcerting to see a partial document when opening a PDF file. Adobe is a leader in accessibility standards and I wondered if you had insight into this topic, I don't see a recommended initial view magnification in the WCAG 2.0 AA standard but I have found references that state that the "page fit" works better for some screen readers when they read a PDF. I'm seeking a "best practice" guideline. Please respond at your earliest convenience. Thank you.

I run a lot of scripts on Acrobat and it would be nice to have the tools tab be the one that opens on launch. Currently, I need to do 4 clicks every time I want to run an action script Tools > Action > Choose My Action > Select Files.

Even a shortcut to specific tools would be amazing! You can do this on all other Adobe programs (assign shortcuts) but you cannot do this on Acrobat and it makes my workflow on this program so much slower.

I saw a lot of requests to remove the tools pane, but don't forget about the people who are trying to automate their workflow!

I am using the latest version of Mac Acrobat DC 2018.011.20038

1- Make a form field.
2- Select it so you can make a <form> with the OBJR
3- Drag it into its proper spot in the reading order.
4- Then move it even one pixel, it will delete itself. This happens on all fields of any type. It also happens if you just resize any field.

Since this Adobe Forum usually asks questions until people give up on the thread I even made a video of the whole thing:

https://drive.google.com/open?id=1S79CQ53xiebkxiXmZawAML2kpSY3O6Bn

By the way, I lost 17 hours of work. When I was done with my form. I just use the alignment tools to make my fields line up, and it deleted every field the Acrobat adjusted itself.

When remediating a document created from Word, we had a group of tables (actually embedded Excel sheets) that auto-tagged as Figures. When the cells in these Figures were manually tagged using the Reading Order Tool they inherited the Bounding Box and Placement attributes of the Figure tag they were within. If the Figure tag was deleted and then the content was tagged this problem did not occur, but who knew this would happen? This caused unexpected issues using several remediation Tools -- Commonlook Validator would not open the file and Axes PDF Quick Fix showed a large bounding box around each table cell selected. The problem did not *appear* to cause an accessibility issues -- the file passed internal Acrobat check and PAC and screen readers did not stumble. However, this cannot really be passing UA as TD and TH should not have these a Bounding Box or Placement = Block attributes which these cells had!

Steps to reproduce
PDF files generated by Microsoft SQL Server Reporting Services 2008R2
Process with 'Accessibility tools, Autotag Document'

Environment (OS, version)
Windows 10, Acrobat Pro DC
2015 Release (Classic) Version 2015.006.30392

Note that files were OK with Windows 10, Acrobat Pro XI (currently on the same workstation)
Note that files had previously been OK with Windows 7, Acrobat Pro DC (prior workstation, no longer available)

Expected Result
Text recognized and assigned text characters
Bullets recognized and assigned 'bullet' character
Accessibility Checker passes content

Observed Result
Bullets assigned text character ('w', 'n', etc. - possibly the different values were based on different shaped bullets)

Running accessibility checker:
Bullets flagged as 'Page Content - Character encoding - Failed'
Some apostrophes in text strings flagged as 'Page Content - Character encoding - Failed'

Using the latest Acrobat DC on MacOS Sierra, the only way to add a summary to a table also removes correct, accessible tags.

The only way to access the table summary is to open the Touch Up Reading Order panel, highlight the table in question, and mark it as a table in the TURO panel--even though the table was already correctly tagged and in the correct reading order. After this is done, the user can right click on the table and add a table summary.

However, doing this changes the <table> tag to two nested <sect> tags and removes any <TH> header cells, which are necessary for accessibility. If a document is already accessible except for a table summary, the person remediating the document has to completely retag the table to get the summary, instead of being able to just add a summary to an already-correct table.

Some accessibility tutorials account for this and include instructions to re-designate the table with the TURO panel, and some just open the TURO panel and right click without having to update the tags (which does not work), so I am hoping this is a bug that can be fixed. Older versions of Acrobat force the user to remove existing tag structure before being able to add a table summary.

This makes a table summary not worth it when you're working with documents at scale, as our company is. It would be really nice to have this feature available to us without all the extra steps redoing what was already done correctly.