Skip to main content
mazdaspeed
Inspiring
September 19, 2024
Answered

Why is ID adding aria-labels to my Reflowable EPUBs?

  • September 19, 2024
  • 1 reply
  • 1189 views

I'm getting aria-labels tags (such as <div id="page6" role="doc-pagebreak" aria-label="2" epub:type="pagebreak">) added throughout my EPUBs and it seems arbitrary. Although it is easy enough to remove them using Regex, they are screwing with my footnote output on export. Like the following, where the second footnote is as expected, but the first footnote has an aria-label in a <div> tag and it causes the <p> tag to be placed after the footnote number.

 

<aside id="footnote-016" class="_idFootnote" role="doc-footnote" epub:type="footnote">
<div id="page205" role="doc-pagebreak" aria-label="201" epub:type="pagebreak">
<a class="_idFootnoteAnchor" role="doc-backlink" href="File1.xhtml#footnote-016-backlink">
13 </a>
</div>
<p class="FtNtTxt">. Sample text 1.</p>
</aside>
 
<aside id="footnote-015" class="_idFootnote" role="doc-footnote" epub:type="footnote">
<p class="FtNtTxt"><a class="_idFootnoteAnchor" role="doc-backlink" href="File1.xhtml#footnote-015-backlink">14</a>. Sample text 2.</p>
</aside>

 

This just started being an issue. It's been a couple months since I last exported to EPUB. Some books I work on have upwards to 800 footnotes and I need the tagging to be consistent so I can operate on the entire set at once, using Regex. This is a mess.

Correct answer James Gifford—NitroPress

Uncheck "Page Navigation" in the General pane of the EPUB export menu, and see if that ends the problem.

1 reply

James Gifford—NitroPress
Legend
September 19, 2024

Uncheck "Page Navigation" in the General pane of the EPUB export menu, and see if that ends the problem.

mazdaspeed
Inspiring
September 20, 2024

Sure enough. Thanks, James.

James Gifford—NitroPress
Legend
September 20, 2024

Fair enough. When I started doing this I was trying support older (and used) devices in 3rd-world countries to be able to manage some pretty large documents, so I stripped everything unneccessary. This is no longer an issue so I should let it go.


It never hurts to have a suspenders-and-belt-and-safety-pin approach, especially in the wild world of EPUB. But at a certain point you have to relax to the fact that there are so many readers in play that no document, other than perhaps the very simplest one, is going to render optimally on all or even most of them. I choose to optimize for Kindle as one fork (which for all its faults is at least consistent across all but a few older devices), and then for Calibre as a baseline EPUB. Anyone using another reader, especially browser-based or OS generic ones, gets what they get. As with PDF, the burden of using a full-featured, standards-compliant reader has to be on the end user.

 

With InDesign plus CSS, you can create optimized EPUB exports that can be updated and replicated endlessly, without the tedious every-iteration editing of the exported file. I find that a worthwhile path.