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

[mazdaspeed]

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.

[James Gifford—NitroPress · Accepted solution]

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

[mazdaspeed]

Sure enough. Thanks, James.

[James Gifford—NitroPress]

One easy fix, anyway. I wish Adobe would remove that checkbox, leave the option disabled and leave it along with all the other new accessiblity features on the Accessiblity pane... it confuses too many users and causes this downstream fault in an overall system that doesn't recognize the code yet. It's of no more importance or use than the rest of the accessiblity stuff... why it was given prominence is a mystery.

[mazdaspeed]

They have also changed something with the choices for footnote output. The choice of "End of Section (Endnotes)" results in an Unordered List, which is totally unacceptable. This used to be my goto because the output was very simple to do Regex on.

This leaves only "Inside a Pop-up (EPUB 3)" as a choice that places the footnotes at the end of a file. The Pop-up EPUB 3 uses the <aside> tag where I prefer <div>, but at least it also adds the "epub:type=" everywhere it's needed for pop-ups. Now ID is adding "role=" everywhere, which is just more crap to remove. 

I break everything down to it's most simple expression and get perfect pop-notes.

• <span class="FtntRfNm" id="footnote-1-backlink" epub:type="footnote"><a href="File1.xhtml#footnote-1">[1]</a>

• <div id="footnote-1" epub:type="footnote">
• <p class="FtNtTxt"><a href="File1.xhtml#footnote-1-backlink">1</a>Sample text1</p>

I also do away with ID's ridiculous 3-digit numeration where the footnote link numbers don't match the actual footnote number.  However, the recent ID changes are making the Regex ever more time-consuming to do.

[James Gifford—NitroPress]

Yes, that changed as well. It's a selective problem that affects those who muck with the export code more than anyone else. I might be forgetting a detail, but the new model, which is standards-compliant, works fine in Thorium, Calibre and Kindle Previewer.

I don't edit export EPUB, nor recommend it as a current practice. The days of hand-assembling e-book files are long past. 🙂

I also don't care for the way any e-book reader handles footnotes, so I use an inline style. That's admittedly not a solution for dozens or hundreds of notes in a book, though.

[mazdaspeed]

I edit the export because I maintain the documents, meaning I will likely make future changes and therefore desire uniformity. Just set in my ways, I guess. It's an hour or two of prevention.

[James Gifford—NitroPress]

Okay. I'll just make my usual passive argument that I haven't edited an exported EPUB in over a decade and haven't been given any convincing reason it's a necessity; the arguments-for seem to devolve to outdated methods and practices that can be abandoned.

I also find no difference in exporting to "end of chapter" or "in a pop-up" — being reader-driven features, both behave exactly the same in my test triad. So the idea that you have to export to an alternate format to preserve a legacy editing process is... well, your choice.

EPUB, like PDF and print, is an end format. When it needs to be changed, you update the source and re-export, not get out the Wite-Out and pencil. 🙂

[mazdaspeed]

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.

[James Gifford—NitroPress]

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.