Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conflict between ACE and Nordic guidelines 2020-1 regarding endnotes #556

Open
AlexanderHugestrand opened this issue Apr 18, 2023 · 6 comments

Comments

@AlexanderHugestrand
Copy link

<body>
  <section epub:type="endnotes" role="doc-endnotes">
    <ol>
      <li epub:type="endnote" role="doc-endnote">

ACE doesn't allow the role attribute on list items. Removing it will trigger rule nordic_opf_and_html_26b, saying that a note reference "must resolve a note".

@martinpub
Copy link
Collaborator

This is somewhat expected, see https://github.com/nlbdev/epub3-guidelines-update/issues/155. Accessibility best practices have changed since the publication of 2020-1, thus the ACE error. From the DAISY Accessible Publishing KB:

Should I use the doc-endnote role?

No. Use of the doc-endnote role is now deprecated due to a technical incompatibility with the core ARIA role module. ARIA does not allow roles from a module to satisfy the requirements of core roles, so although doc-endnote behaves like a list item, it technically does not fulfill the requirement that lists have list item children. That makes it invalid in both HTML list elements and as a child of the ARIA list role.

While AT uses should not experience any problems if you have already used the role, it is best to avoid it moving forward to avoid errors in your content.

The role is also generally redundant. If a section of notes is identified using the doc-endnotes role, users and assistive technologies will understand the list within the section contains the endnotes.

The section of 2020-1 dealing with notes is not explicit about the use of @doc-endnote, so I think the rule could be updated. Maybe it could look for a <li> or <p> with a @doc-endnote <section> as parent?

I'm not sure if total ACE (e.g. EPUB Accessibility) compliance is possible with 2020-1 (see e.g. https://github.com/nlbdev/epub3-guidelines-update/issues/49), so the priority of this issue might also be moved to the upcoming revision of the Nordic Guidelines. But noting that this issue is possible to fix within the framework of the current guidelines text.

Ping @AndersEkl @josteinaj @oscarlcarlsson etc.

@josteinaj
Copy link
Member

If the role is needed for validation purposes, we might need to change it to a class instead of removing it.

@martinpub
Copy link
Collaborator

Maybe we can still use @epub:type "endnote" for that purpose? It's not deprecated in EPUB SSV 1.1. As noted in the specs, it will not fill any accessibility purpose, but what we're after here is semantics for production purposes.

There is no explicit conflict in the current guidelines, but an indirect one, 2020-1 says "Footnotes and endnotes are required to be handled in accordance with the recommendations in the Accessible Publishing Knowledge Base", and the example present currently in the KB is an endnotes section without any endnote semantics on the individual notes.

Perhaps this could wait until an update?

@AndersEkl
Copy link
Collaborator

For us, this is not a huge problem, as we rarely have notes in our material. But if it causes validation issues for the rest of you, maybe we should fix it?

@martinpub
Copy link
Collaborator

The issue is with ACE validation currently, but we will still have other ACE issues that cannot be amended in 2020-1 (e.g. unlabelled asides), so I'm not sure how prioritised this is. It depends on how quickly the revision work can start, and how to go about it (minor vs major update, etc.).

@AndersEkl
Copy link
Collaborator

Ah, ok... Then I think we can wait until we do a proper revision. Let's discuss that next week when I am in Malmö.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants