Open dauwhe opened 4 years ago
1. Should book chapters have both epub:type="chapter" and epub:type="bodymatter"?
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.
2\. Is it OK to have these on the same element? `<section epub:type="bodymatter chapter">`
For epub:type, yes. Again, it's not doing anything practical, and there's no precedence of values, unlike with ARIA role.
3\. Should we discourage using epub:type on `<body>` to ease the transition to aria roles?
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 <body epub:type="bodymatter">
, for example, which has no equivalent aria role, anyway, so is entirely benign.
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 like for example
<section epub:type="bodymatter chapter" role="doc-chapter">
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 <body>
because they are trying to add role="doc-*" and tools like ACE are looking for matching role's for epub:type so by keeping epub:type and its corresponding roles together and not on the body element I would think is the best solution here.
@TzviyaSiegman
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.
We won't be checking backlists titles, only new titles coming off the production pipeline.
they are trying to add role="doc-*" and tools like ACE are looking for matching role's for epub:type
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).
tools like ACE are looking for matching role's for epub:type so by keeping epub:type and its corresponding roles together
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 epub:type
is being used for accessibility.
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 epub:type
was conceived as a way of providing that functionality while also trying to layer on accessibility by tying the attribute to role
(i.e., the idea of killing two birds with one stone). But we never defined how that was supposed to happen or what the restrictions were.
I'm hesitant to now say that uses of epub:type
are incorrect based on ARIA usage, or that you have to put a matching role wherever you find the attribute. It's fine as a message along the lines of "here's a way you might make this document more accessible", but enforcing roles is not always going to be in keeping with how publishers have used the attribute.
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 epub:type
or what alternative will be used. It's not going to be role
, though. We aren't preparing people to transition off epub:type
, in other words. They need to stop using it with the idea of enhancing accessibility now.
So we should promote the use of role and doc-* but downplay the use of epub:type? We need to include some semantics so loosing both seems the wrong thing to do. MathML didn't have any semantics written into the original spec (at least for presentational) and now they are having to go back and add semantics in order to disambiguate these expressions so that they are announced correctly. By adding these semantics now then reading systems have the opportunity to offer enhancements by knowing what a particular section of code in the EPUB really is.
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
So we should promote the use of role and doc-* but downplay the use of epub:type?
Yes. For accessibility, we shouldn't even be mentioning epub:type
beyond the message that it has no particular value for that purpose.
Outside the nav doc, the only thing epub:type
is used for is pop-up footnotes. That's potentially a bad thing in itself, as we diverge from the web by creating special behaviours. EPUB has always been caught a bit between being its own format and being web conformant, but I'd hazard to say that diverging is now seen as a bad thing.
If all we had wanted was accessibility, we could have just told everyone to use role
from the start. That's what makes epub:type
so problematic. It really was meant to fill another function, and one that we were mostly leaving to publishers to define for themselves.
Benetech is in a unique position to help guide publishers looking for accessibility certification to start doing the right thing
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 role
where epub:type
is being used, for example, it's definitely worth having a conversation with the publisher about why they aren't using role
to see if they just aren't aware (and I expect it's something you'd do). I just wouldn't go further than that unless I had established with the publisher that they want (mis)uses flagged.
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?