Closed acabal closed 2 years ago
Hello, thank you for reporting this! Specification reference: https://www.w3.org/TR/dpub-aria-1.1/#doc-epigraph @rdeltour what's your perspective? (EPUB-Check)
Another point of interest is that article
denotes a document
which is itself a structure
( https://www.w3.org/TR/wai-aria-1.1/#article ) whereas section
which is superclass of doc-epigraph
denotes a structure
( https://www.w3.org/TR/wai-aria-1.1/#section )
Chiming in from the ARIA side: https://www.w3.org/TR/html-aria/#el-article is likely the source. There's been a recent shift in ARIA to more actively signal misuse of elements.
IMHO an
<article>
should be allowed to be an epigraph in an ebook
Setting a role on an element overrides its element-level semantics; in this case, the element ceases to be an article from an accessibility point of view. Well, if it's allowed anyway.
That's why general advice nowadays is not to change the semantics of HTML elements - it leads to unexpected behavior for users. More specific roles are still ok, i.e., it would make sense on a section because doc-epigraph is a subclass of the section role.
Setting a role on an element overrides its element-level semantics; in this case, the element ceases to be an article from an accessibility point of view. Well, if it's allowed anyway.
Right; that's why I suggest Ace be adjusted to not emit an error when adding the epub:type
value as an ARIA role would result in an invalid ARIA role. I think epubcheck is correct in its output here in the sense that it's conforming to the spec, but Ace's output is (I think?) more of a suggestion than an issue of strict spec conformance. Maybe I'm wrong in that though.
To clarify the use case a little: in this Robert Frost collection, the ebook is a collection of poems, each of which is an <article>
because we can anthologize each poem independently of the ebook. The epigraph is also a complete, titled poem, which can be (and has been) anthologized independently of the book. Thus, it is an <article>
, but also an epigraph at the same time.
I wonder if this would be worth raising to whoever is working on ARIA?
@rdeltour what's your perspective? (EPUB-Check)
@pkra's comments are on point. The rules on what ARIA roles (including DPUB ARIA roles) are allowed on which HTML elements are defined in the ARIA in HTML specification. This is the authoritative resource used by conformance checkers (EPUBCheck, W3C HTML validator).
That said, @acabal you're right to interpret Ace's output as a suggestion rather than a conformance or accessibility failure. The epub-type-has-matching-role
rule has a "minor" severity level and is a best practice rule (not a conformance rule).
The original intent of adding this rule in Ace was to help publishers who mistakenly used epub:type
for accessibility reasons to migrate to ARIA roles. But it's definitely not wrong to use epub:type
and not DPUB ARIA.
Related fix (allow epub:type
values for deprecated ARIA roles):
https://github.com/daisy/ace/commit/9e9a0c150e1f102c7f1b874c21ec645d185ee891
Ace v1.2.2 Node v15.14.0 Ubuntu 20.04
Consider the following XHTML file in an epub:
Ace emits an
epub-type-has-matching-role
error:Element has no ARIA role matching its epub:type: <article id="epigraph" epub:type="epigraph z3998:poem">
.If we add a
role="doc-epigraph"
attribute to the<article>
element, then Ace is appeased. But then when we run epubcheck on the corrected file, epubcheck has this complaint:RSC-005: Error while parsing file: value of attribute "role" is invalid; must be equal to "application", "article", "document", "feed", "main", "none", "presentation" or "region"
.So, either way one of the checkers is unhappy.
I'm not certain what the actual schemas say, but IMHO an
<article>
should be allowed to be an epigraph in an ebook; in this real life use case, the<article>
is a poem by Robert Frost that can be syndicated/anthologized independently of its ebook (thus<article>
is the semantically correct parent element)--but in the ebook's context, the poem is actually the epigraph of the book. Thus, I would suggest that epubcheck should be adjusted.However I suspect my opinion is irrelevant when considering of the actual specs, and I assume epubcheck's implementation is correct. In that case Ace should be corrected to not emit
epub-type-has-matching-role
if theepub:type
attribute value is actually an illegalrole
attribute value given its element's schema.