doc-footnote produces an error #1018
Comments
|
What element are you using it on @clapierre ? |
|
This was from one of a conversion vendor. but it seemed it was allowed on an aside SO I see the problem now they made a section with doc-footnote which wasn't a footnote and the real footnote was contained in that section in the aside. Where do we spell out which elements each doc-* is valid? |
|
@clapierre |
|
Thanks @laudrain very helpful https://idpf.github.io/epub-guides/epub-aria-authoring/#sec-usage |
Yes, we recently updated the document to add the list of elements that roles are allowed on. In addition to what is listed in the column, you can add roles to any of the elements listed after the table (these all accept any role). So in the case of footnote, One thing to be aware of is that if you have a list of notes, you'll need to put |
What am I supposed to do if I have a list of notes but they are footnotes and not endnotes? |
Sorry, I'm not sure I understand your issue. ARIA roles are used to create the accessibility tree and inform assistive technologies, so what software are you referring to (is this a specific reading system?) and what rendering do you mean? If you want pop-out footnotes in some reading systems, you can also add an If you just want to make a list of footnotes, you can add the doc-footnote role to an element within each list item instead of to the list item itself. See w3c/epub-specs#1316 (comment) for an example. |
|
I just find it a bit weird that it's okay to put
Some reading systems use ARIA roles to figure out if an item is a footnote (rendered in-page) or endnote (no special rendering) How will they behave if
Sure, that works as a workaround, but why can't I put it on the |
Actually the next version of DPUB-ARIA will be deprecating doc-endnote NOTE Same for NOTE |
It's not okay to put But more to your question, when you add a role to an element you change its nature to assistive technologies. So because That's why you can't put any ARIA roles on any element or use them in any situation. Their use has to be consistent with the underlying markup model and the effect it will have on AT. You can make documents entirely unreadable for their intended audience by misusing ARIA roles. And that's the long story to why there were two roles. ARIA roles aren't context sensitive, so if a role inherits from list items it can only be used as the child of a list element. To allow footnotes to be placed anywhere, not just within a list, it didn't get the same inheritance. Moving forward, there will just be footnotes, and if you want to make a list of them just wrap them in a list.
I'm still not sure what you mean by "rendered in-page"? If you mean a reading system will actually format them at the bottom of a virtual page, I haven't seen that done and don't expect it's technically feasible to do.
The only special formatting I'm aware of is pop-ups, and I believe that's mostly done based on |
|
Thank you for your answers.
Maybe it shouldn't be recommended anymore then. This is the error message I get from EPUBCheck 4.2.5 if I use
Yes, KOReader and I think coolreader do that. |
Yes, we're working on moving DPUB-ARIA 1.1 forward. This may be something worth fixing in advance, though. @rdeltour? The Ace validator does a better job of checking for proper ARIA use as well as other common accessibility pitfalls that epubcheck doesn't catch.
Interesting. I'll have to have a look. Thanks for the pointer! |
That particular message ( In fact, I'm not quite sure how to fix this: if the schema is updated to disallow If we want to be proactive, we should probably open an issue on the HTML validator, and see how they deal with deprecation of attribute values. |
Ya, but that probably means waiting for 1.1 as they don't usually fix for in-progress specs. I was only thinking of a schematron warning when doc-endnote or doc-biblioentry are used. Something we could dispose of easily once officially corrected. But off the top of my head I can't remember if we implement our own schematron checks on top of xhtml content documents. |
Ok I see! Yes we do have schematron checks for XHTML. |
|
Given the valid <section role="doc-endnotes">
<h2>Notes</h2>
<ol>
<li id="6baa07af" role="doc-endnote">Additional results of this study can be found at … </li>
<li id="7b2c0555" role="doc-endnote">…</li>
…
</ol>
</section>And the valid <section role="doc-endnotes">
<h2>Notes</h2>
<ol>
<li id="6baa07af">
<p role="doc-footnote">Additional results of this study can be found at … </p>
</li>
<li id="7b2c0555">
<p role="doc-footnote">…</p>
</li>
…
</ol>
</section>Am I correct to assume that just replacing <section role="doc-endnotes">
<h2>Notes</h2>
<ol>
<!-- invalid -->
<li id="6baa07af" role="doc-footnote">Additional results of this study can be found at … </li>
<!-- invalid -->
<li id="7b2c0555" role="doc-footnote">…</li>
…
</ol>
</section> |
Right, the problem is that we were told after the 1.0 release that roles defined in modules like dpub-aria cannot satisfy the child role requirements of roles in aria core. That's why doc-endnote is deprecated. You can't simply swap it to doc-footnote as that would completely break the list semantics as it doesn't inherit from listitem, and even if it did it would also be invalid for the same reason doc-endnote can't fulfill the list role requirement. The 1.1 example you've quoted is no longer valid, by the way. There's an updated working draft coming soon. In it, endnotes are implied on the immediate list item descendants of a doc-endnotes marked section and the use of doc-footnote is not allowed. This was done to avoid the ambiguity of whether the content within the list item is a footnote or endnote. But this does make things simpler, as you can simply drop the explicit role and there's still an assumption that the list items are endnotes. Until 1.1 gets out of draft stage, it's probably better to refer to the latest editor's draft. |
doc-footnote should be valid. doc-footnotes is not valid which was a previous issue which has been closed.
from the DPUB-ARIA spec.
doc-footnote
Ancillary information, such as a citation or commentary, that provides additional context to a referenced passage of text.
The text was updated successfully, but these errors were encountered: