Description: If you have LibreOffice Writer that hat "Table of Contents" or "Index of Tables" or "Table of Figures" or other table generated by "Insert" -> "Table of Contents and Index" and then export to PDF as PDF/UA. Then exported file is not PDF/UA compliant. (Links in generated table are missing Alternative Descriptions) Steps to Reproduce: 1. Create blank Writer file 2. Insert few Heading tiles Insert some table and images and add to all of them captions 3. Insert "Table of Contents" and/or "Index of Tables" and/or "Table of Figures" 4. Run Accessibility check (under Tools) 5. Fix all possible problems that Accessibility check finds 6. Export to PDF as PDF/UA 7. use some PDF/UA tester (example PAC 2024 from https://pac.pdf-accessibility.org) Actual Results: PDF/UA tester reports that file is not PDF/UA compliant. "All links of the generated table of contents are missing value in Alternative Description" Expected Results: PDF/UA tester reports that file is PDF/UA compliant. Reproducible: Always User Profile Reset: Yes Additional Info: *Tested on different computers.
Created attachment 201683 [details] test file
Created attachment 201684 [details] Generated PDF/UA from test file
Created attachment 201685 [details] PDF/UA test report for test file
Hi Miha, Could you also add to what extent this has an impact on the end user experience, especially for screen reader users? I'm asking this because PAC flags many issues that don't seem to have any kind of impact on the user experience.
Hi Christophe, unfortunately no. I will try to find some user that actively uses screen reader and report. I found this incompatibility because in our county there is new law that mandates that all government/public agencies/institutions should make all their public files in machine readable form for those that need it for accessibility. So all PDF should be in PDF/UA. I work as IT in one of those agencies. So creating files that PAC flags as prefect would be ideal to make lawyers happy. MS Office creates a lot worse PDF/UA than LibreOffice so I look a that law as great opportunity to make more users aware about strengths of LibreOffice.
Hi Miha, Does the law explicitly reference the PDF/UA standards (ISO 14289-1:2014 and/or ISO 14289-2:2024) as standards to which all PDF documents must conform? Or is this just what a monitoring institution requires? I'm asking because I have seen a monitoring institution for the Web Accessibility Directive in the EU check PDF documents with PAC without knowing that many of the issues flagged by PAC are a waste of time to fix. In fact, the previous version of PAC even flagged links without a text alternative because ISO 14289-1:2014 required that links have a text alternative. Duff Johnson, one of the co-authors of PDF/UA, later admitted on Twitter that this was an error in the PDF/UA standard. So if the ISO standard is not in the law, please demand evidence that the issues that are reported have a real impact on users.
Hi Christophe, thanks for very interesting info! I wouldn't be surprised if our monitoring institution also don't know that about PDF/UA. In that law I'll se reference to "SIST EN 301 549 V1.1.2" and around 11 EU directives. The monitoring institution states in their files PAC as tool for checking files. Looks I have some legal papers reading time to do :/ I'll report back If I get some concrete evidence from monitoring institution.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e2be650d97765945538614463b9269acb164947c tdf#167409 set alt. text to the internal hyperlinks in a TOC It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/a2efe54a1d813b852763479a351a1045bc5c9027 tdf#167409 set alt. text to the internal hyperlinks in a TOC It will be available in 25.8.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks Tomaz for this very important fix, would you please then set the status of it from unconfirmed to the appropriate one? BTW I can confirm the bug, but as there is already a fix, it is irrelevant. Looking forward to see it already in 25.08, that would be great. This is an example of how flexible and reactive the community is, I will mention this bug as an example for it in my next talks.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9955ff410b1b8949a9c9c222f1f08cb8b55f48cd sw: test for tdf#167409 - check PDF Annotation /Contents It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
So I also added a test for this issue, which checks the exported PDF that the /Contents key is found for the TOC link in the example document and it checks the content. Note that the TOC needs to be updated (context menu) in the existing document for this to have an effect, because the alt. text is written to the link when we create/update the TOC data.