Accessibility/validation error conundrum

So I’m working on exporting final files in both a digital PDF and an EPUB. There are a number of accessibility things I have to address in the PDF and one of them was table summaries, so I added them into the HTML so I wouldn’t have to remediate every PDF export in that way.

However, once I added those, now I’m getting EPUB validation errors. I guess if EPUB doesn’t support the table summary, then I don’t have a choice, but I was curious what other people do; do you just use Acrobat to address any last accessibility concerns in the PDF and add table summaries manually every time you export a new file? Is there a sneaky way to hide that code from the EPUB? Is there a way other than adding the summary in the table tag to add the summary in Pressbooks?

Here is the validation error:

ERROR(RSC-005): ./Downloads/Processes-1679682392.epub/EPUB/chapter-019-the-art-of-editorial-conversation.xhtml(20,6255): Error while parsing file: attribute "summary" not allowed here;

Similarly, in the same PDF I’m getting “Lbl/LBody” errors on every footnote reference. Has anyone experienced that as well?

Hi @allisonbrown for the first issue, the summary attribute for table descriptions was deprecated in HTML5 (see <table>: The Table element - HTML: HyperText Markup Language | MDN or <table summary=""> ») in favor of other approaches like caption. See HTML Standard or this old set of draft recommendations: Table Summary | Tables | WAI Web Accessibility Tutorials for some other implementation possibilities that shouldn’t produce EPUBcheck validation errors.

As for the second issue with Adobe validation errors related to footnote markup, we asked about in the PrinceXML forums a couple years ago about the Lbl/LBody errors that Acrobat throws: Accessibility in footnotes - Prince forum. They seem to think it’s a false positive and Adobe’s checker is incorrect in this case – they pointed to specifications that seemed convincing to me. I’m not aware of this issue causing any meaningful barriers to access for readers with disabilities or who prefer to use assistive technology when interacting with digital PDFs. If that’s not correct, let us know an we can try to bring this up again.

Thanks for all this info! I’m behind, I guess.

For PDFs I’ve just been going by Adobe’s checker; it looks like the PAVE checker had the same result; are there any other options for reviewing PDF accessibility?

Hi @allisonbrown – I’m afraid I don’t know that much more about automated PDF accessibility review tools. I think the crux of it comes down to whether items other than LI are permitted to have Lbl as a child. The person who answered our question on the PrinceXML forum indicated that the ISO standard for PDFs says that Note and BibEntry structure elements are permitted to have Lbl as a child element. I can’t read the ISO document myself without paying for it, so I’m taking their word for it. If that’s true, then I think that Adobe and PAVE’s automated checkers can be ignored on this point, as they are providing false negatives – Lbl and LBody do NOT have to be children of LI – they can also be children of Note and BibEntry (and possible Reference elements). I’d recommend asking Adobe about this, but I don’t know if you’d get very timely or accurate answers in their forums, based on my past experience there. Woudl be delighted to be mistaken about this, though.

1 Like