PDF/UA requires that hyperlinks have <alt> contents. LibreOffice Table of Contents user interface does not let user insert <alt> contents when hyperlinks are selected (LS and LE buttons). However, inserting manually each <alt> entry in the TOC will be highly inefficient, and can be destroyed on each TOC update. There should be an option to fill the <alt> contents with the (unformatted) text itself. For example, Entry number (#E) and Entry (E) will be enough, I guess. The option can be "Fill hyperlink alternate text with Entry number and text" checkbox. Activated when LS and LE buttons are selected, otherwise, dimmed.
Hi Olivier, If I understand this bug report correctly, it consists of two issues (on the ODF side): 1. The GUI provides no mechanism to add text alternatives to any types of hyperlinks (both normal links and ToC entries), i.e. authors can't do anything that adds an office:title attribute to text:a elements. (Appendix D.2 "Hyperlink Titles" of Part 3 of the ODF 1.3 spec explains that office:title on a text:a element should be exposed to assistive technologies as the "accessible description".) 2. When you edit content.xml to add the office:title attribute to text:a elements, this elements does not get exported to PDF. On the PDF side, Link tags (both for regular hyperlinks and descendants of TOCI elements) have a number of attributes and values: - Type (Link) - Title (empty) - Actual Text (empty) - Alternate Text (empty) - ID (empty) - Language. In order to satisfy PAC 2021 (PDF Accessibility Checker 2021), Link tags need an Alternative Text. So we need 1. a way to fill in office:title on the authoring side, and 2. a mapping between ODF's office:title and PDF's Alternative Text.
In case of a ToC it would be inconsistent to have another <alt> item additional to the visible LS/LE/... configuration. We could perhaps add it always automatically. But I wonder what benefit the impaired user gets from this description. Isn't it clear from the chapter name?
@Heiko The link text (or the text of the ToC entry) is sufficient for the accessibility of the ODF file. The issue is purely about PDF/UA compliance, which requires a text alternative for links. (It's ridiculous, but that's what the standard requires.)
So let's just use the ToC label by default. No fuss with the UI.
(In reply to Heiko Tietze from comment #4) > So let's just use the ToC label by default. No fuss with the UI. +1
After doing some more checks with OpenoOffice.org 3.3.0, I have found the following: 1. The issue already existed in tagged PDF files exported from OpenOffice.org Writer. For this reason, I'm setting "Version" to "Inherited from OOo". 2. Fixing the PDF generated by OOo.org 3 by adding a Text Alternative to each of the TOCI entries in the table of contents does not fix the issue reported by PAC 2021, which still reports missing text alternatives. 3. Fixing the PDF generated by OOo.org 3 by adding a Text Alternative to both the TOCI tags and the LINK tags triggers a "Nested alternate text" error in Adobe Acrobat Pro's accessibility check (and a higher number of issues in PAC 2021 than after the previous step). 4. Fixing the PDF generated by OOo.org 3 by adding a Text Alternative to each of the LINK tags solves the issue. (In my test document, each TOCI tag contained a P tag containing two LINK tags: one for the text from the Heading itself and one for the page number.) Based on this, it seems we need to add the text alternative to the LINK tags and leave the TOCI tags alone.
fixed on master (but i didn't test all possible sources of links...)
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fa3f04bdd4f73a1b3be70dfb709c44638ef7e3d9 tdf#148934 PDF/UA export: add Contents entry to Link annotations It will be available in 7.5.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/c5a8728d8f9e943bad4bb55dbde30ae9eceefecf tdf#148934 PDF/UA export: add Contents entry to Link annotations It will be available in 7.4.3. 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.
Created attachment 184765 [details] The example file exported to PDF in PAC 3 tool Verified with attachment 183340 [details] from bug 151826 in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f1830bff71847a9c17715cff52383956719847fe CPU threads: 14; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: threaded No complaints about missing alternate description.