Links in TOC have incorrect alt text in PDF generated based on HTML5 & CSS
Posted: Wed Jul 13, 2022 7:23 pm
We're attempting to create accessible PDF's from the map-based version of the HTML5 & CSS transformation scenario. When we set the pdf.accessibility parameter to 'yes', the <Link> tags associated with the table of contents entries are automatically populated with the following value for the Alternate Text property: "No alternate text specified"
Since the TOC entries are generated from the topicrefs in our maps, we're not setting any alt text (and it doesn't appear that you even can). When a screen reader (tested with both JAWS and NVDA) reads these TOC entries, it reads this default text instead of the name of the TOC entry. If you manually remove the value of the Alternate Text property, the screen reader correctly reads the TOC entry.
We found this same behavior with XSL-FO based publishing (using the default Apache engine) and separately reported that issue to this forum. We were hoping that switching to the newer HTML5/CSS based publishing would solve this issue but it appears that the issue is still present.
Thanks for any help with this.
Since the TOC entries are generated from the topicrefs in our maps, we're not setting any alt text (and it doesn't appear that you even can). When a screen reader (tested with both JAWS and NVDA) reads these TOC entries, it reads this default text instead of the name of the TOC entry. If you manually remove the value of the Alternate Text property, the screen reader correctly reads the TOC entry.
We found this same behavior with XSL-FO based publishing (using the default Apache engine) and separately reported that issue to this forum. We were hoping that switching to the newer HTML5/CSS based publishing would solve this issue but it appears that the issue is still present.
Thanks for any help with this.