multiple epub:types for same document #2
Comments
At this point, unless the epub:type value actually does something in reading systems that you want (footnotes), or you're using it in your production processes, there's no need to use any values in the content.
For epub:type, yes. Again, it's not doing anything practical, and there's no precedence of values, unlike with ARIA role.
This is a bit of a hard one, as it depends on what your expectations are. If you're using it with the belief it enhances accessibility, then yes. But if you're using it purely for internal production purposes, then we'd be imposing unnecessary restrictions (depending on what we mean by discouraging, of course). You could have |
|
in GCA we have been telling publishers not to have anything on the element. I agree its fine but I agree with Dave that as we start moving away from epub:type to roles I think it would be easier to transition if nothing appeared on the body element since you don't want to add something like role-"doc-chapter" and replace the epub:typ=chapter if that was say on the . Also keeping epub:type and its corresponding role (when there is one) together would also help the production workflow. Is there anything preventing the use of both on the same section element? |
|
I really hesitate to create best practices for epub:type at this point in time. They are, for the most part, useless. If a tool is using them for ARIA mappings to signal aria mappings, the tool is getting info from the wrong place. If we place restrictions on epub:type now (even by way of warnings in a tool like GCA) we are effectively flagging hundreds of backlist titles. |
|
The problem is we are seeing publishers put roles on |
We won't be checking backlists titles, only new titles coming off the production pipeline. |
Ace is known to be overzealous and too simplistic with this mapping check. This was kinda useful at first to get people to adopt DPUB ARIA, but we have plans to step down (lowering the severity and be more permissive in the mapping logic). |
But whether ace should be doing this is arguable and something we need to discuss. We're looking at the issue from only one dimension -- that That's part of why it was created, for sure, but it wasn't the sole motivator for the attribute, and arguably not the primary one. At the time of 3.0, publishers wanted a way to embed their own semantics and use EPUB in in-house production (and still do, apparently), so I'm hesitant to now say that uses of Even if we only look at this from a forward perspective, putting roles on elements is not a requirement of WCAG conformance, so unless we know that a publisher isn't using the attribute for their own purposes, it's hard to say that anything they do is wrong or has to be matched. Whatever successor there is to EPUB 3 has to figure out what future there is for |
|
So we should promote the use of role and doc-* but downplay the use of epub:type? Benetech is in a unique position to help guide publishers looking for accessibility certification to start doing the right thing so that we do have content out that Reading Systems can rely on having this semantically rich data and can offer unique enhancements to their customer. So we just need to know what we should be recommending that publishers start doing. Obviously it won't be required but having this in their EPUBs at least gets us out of the chicken/egg paradox. |
|
@clapierre please see minutes from the PWG meeting in May 2018 for discussion https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-05-30-pwg.html#section2 |
Yes. For accessibility, we shouldn't even be mentioning Outside the nav doc, the only thing If all we had wanted was accessibility, we could have just told everyone to use
Sure, I'm not suggesting that you shouldn't help guide publishers to the right accessibility attribute. I'm just concerned when we talk about "discouraging use". That sort of language suggests warnings and failures and those sorts of things to me. I'm all for pushing publishers to use the right tools, but in this case we just need to tread lightly. If there's a case where the accessibility can be improved by using |
Perhaps the most common file in any epub is a chapter.
Should book chapters have both epub:type="chapter" and epub:type="bodymatter"?
Is it OK to have these on the same element?
<section epub:type="bodymatter chapter">One prominent organization was recommending two nested sections, one for each epub:type value, which seems like unnecessary complexity.Should we discourage using epub:type on
<body>to ease the transition to aria roles?The text was updated successfully, but these errors were encountered: