Matt, you have done an excellent job with this. I do see one item. Where it says: Moreover, EPUB creators cannot use this property to exempt themselves from accessibility requirements where no legal exemption exists.

Knowing that publishers are distributing there content in many different markets, and where distributors have central databases of content that is available in many countries, this statement seems out of place. The publisher would put this in their publication, but it would be up to the distributor to accept the content or not. I think this metadata would mean that a publication may not make it into a distributors catalog if the jurisdiction has no exemption.

Only admin issues

• respec should indicate that this is not a rec-track document
• it is not the EPUB WG any more :-) it should be set to wg/pm
• I wonder whether it is possible to make the title a bit more indicative that we are talking about EPUB stuff... Or even EPUB A11y stuff...

• respec should indicate that this is not a rec-track document

I think we're good with this. It has noRecTrack: true in the metadata.

• it is not the EPUB WG any more :-) it should be set to wg/pm

Ya, I grabbed the metadata from an existing note and didn't correct. But... there's no PMWG according to the current list of groups: https://respec.org/w3c/groups/

How do we get that updated? Is it through the respec tracker?

• I wonder whether it is possible to make the title a bit more indicative that we are talking about EPUB stuff... Or even EPUB A11y stuff...

Good point. I've changed the title to "The EPUB Accessibility exemption property".

I think this metadata would mean that a publication may not make it into a distributors catalog if the jurisdiction has no exemption.

Right, I'm fine with leaving the sentence you've quoted out. The one before probably says enough. I was just trying to highlight that this isn't some "get out of jail free" card where you can write any old exemption you want in.

• respec should indicate that this is not a rec-track document

I think we're good with this. It has noRecTrack: true in the metadata.

• it is not the EPUB WG any more :-) it should be set to wg/pm

Ya, I grabbed the metadata from an existing note and didn't correct. But... there's no PMWG according to the current list of groups: https://respec.org/w3c/groups/

Ouch. I will contact Denis.

How do we get that updated? Is it through the respec tracker?

• I wonder whether it is possible to make the title a bit more indicative that we are talking about EPUB stuff... Or even EPUB A11y stuff...

Good point. I've changed the title to "The EPUB Accessibility exemption property".

+1

Ya, I grabbed the metadata from an existing note and didn't correct. But... there's no PMWG according to the current list of groups: https://respec.org/w3c/groups/

It should work now with pm as the short name of the WG

It should work now with pm as the short name of the WG

Cool. Should I open a separate PR to change all the specs and notes to use the group name so we don't have to remember to do it each time we update them?

It should work now with pm as the short name of the WG

Cool. Should I open a separate PR to change all the specs and notes to use the group name so we don't have to remember to do it each time we update them?

Well... that would republish all the notes due to echidna, which is still alive for the notes. Do we want that?

cc @w3c/w3c-group-145018-members

Do we want that?

Hm, tough question. It's not critical, but they are directing people to the old WG until we update them.

Is there any other feedback on this, or should we look at getting approval to publish it at the next meeting?

Until we publish, it'll be a blocker on #2572 (and possibly any change @gregoriopellegrino might want to make to the mapping document if it needs a reference).

Thank you Matt for this work. Here are some comments on my side:

• the examples report conformane=none and an exemption, in my opinion we should also provide for the case when conformance is not present and there is exemption alone: in the first case we are dealing with an EPUB with known accessibility problems (which falls inside an exception), in the second case we are dealing with an EPUB that has not been checked because it falls inside an exception
• The official names of the EAA exceptions are: Microenterprise, Disproportionate burden, Fundamental alteration. We asked EditEUR to align the ONIX code names with those in the law (they did), I think it would make sense here as well
• Shall we indicate that only one exception can be present for the EAA? Are we being too restrictive?

After the edits I reserve the right to have Cristina review it, so I can also get her opinion on the formal aspects.

The official names of the EAA exceptions are: Microenterprise, Disproportionate burden, Fundamental alteration.

Okay, that makes more sense. It was weird that the exemption names weren't matching the cited text.

Shall we indicate that only one exception can be present for the EAA? Are we being too restrictive?

The cardinality field in the property definition is zero or more (corrected in the next commit from a copy/paste error of one or more), so we aren't restricting anyone from having multiple. I didn't think it would make sense to show multiple if they're all for the same jurisdiction, as I assumed publishers would pick the most appropriate to their situation, but if you think publishers in the EU will list multiple values I can add another example.

in my opinion we should also provide for the case when conformance is not present and there is exemption alone

Sure, I'll add an example for this case, too.

Would it make sense to drop the use of the refines attribute from this property?

The more I look at it, the more I wonder what purpose the attribute serves. It's not really a statement about the conformance claim itself (like who evaluated and made the claim), but a tangential piece of information that explains why conformance doesn't have to be met.

In other words, you only need to find an exemption statement to know everything you need.

Would it make sense to drop the use of the refines attribute from this property?

The more I look at it, the more I wonder what purpose the attribute serves. It's not really a statement about the conformance claim itself (like who evaluated and made the claim), but a tangential piece of information that explains why conformance doesn't have to be met.

In other words, you only need to find an exemption statement to know everything you need.

Yes, also because in case there is no conformsTo, what does the refines attribute refer to?

Okay, I think all the changes you've requested are done now, @gregoriopellegrino.

Instead of adding an example without a dcterms:conformsTo property, I put a note in after the first example saying that it is not required to have one but it is best practice. I know people who are exempt probably aren't bothering to check, but it's better to know the publication doesn't meet standards than that the status is unknown when possible. Let me know if that works for you.

Otherwise, I've made clear in the extends field of the property definition that it must not be used with a refines attribute.

In order to be comprehensive, can the bold text be added?

Some jurisdictions provide exemptions for meeting accessibility requirements. For example, the European Accessibility Act provides three exceptions for meeting its requirements: to microenterprises that employ fewer than ten people and which has an annual turnover not exceeding EUR 2 million or an annual balance sheet total not exceeding EUR 2 million, if accessible production would prove an undue burden, or if making accessible would substantively alter the product.

That paragraph had a couple of instances of the onix phrasing (undue burden and substantive alteration) as did the definitions. I've gone through and changed them all to the EAA terms.

Hello, in order to encourage publishers to produce EPUBs as much accessible as possible, and not completly forget about accessibility, would it possible to be complete the exemption metatada with new values?

As a matter of fact, the fundamental burden and alteration exemptions are not always all or nothing issues.
Sometimes they concern the whole digital publication indeed (ex : album for kids => burden and alteration).
Sometimes, they concern only part of publication's content (ex: cookbooks, travel guides, dictionaries, textbooks, exercice books) :
1- image (for visually impaired people)
2- audio transcription (for hard of hearing people)
3- video caption (for hard of hearing people)
4- video subtitle (for all, when sound not hearable/understandable)
5- video description (for visually impaired people)
6- interactive game/exercise (for visually impaired, and motor-handicapped people)

Impaired people need to know if a publication is accessible, EXCEPT for this and that ONLY, thanks to detailed accessibility metadata.
So do certification, and control organisms/authorities. They need to know when a publication is not exempted, EXCEPT for this and that ONLY.
As a matter of fact, to grant exemptions, they need to check that the publisher has done its best effort, to make the publication as much born accessible as possible.
They need to know what content is exempted (see above), for what reason (disproportionate burden, and/or fundamental-alteration).

In order to help everybody, would it be possible to add more detailed values for the meta property="a11y:exemption"?
Here a first proposal (db = disproportionate burden, fa = fundamental-alteration):

• eaa-db-image
• eaa-db-audio-transcript
• eaa-db-video-caption
• eaa-db-video-subtitle
• eaa-db-video-description
• eaa-db-interaction
• eaa-fa-image
• eaa-fa-audio-transcript
• eaa-fa-video-caption
• eaa-fa-video-subtitle
• eaa-fa-video-description
• eaa-fa-interaction

The accessibility summary already exists for explaining why the content is not accessible. I don't have an issue with noting to use the summary when claiming an exemption, but turning this property into a duplicate of it that has to be processed by reading systems to present to users doesn't sound all that helpful. We'd have to account for every possible reason a publication might fail, so you'd minimally need values to match every WCAG A/AA success criterion for each exemption.

Unfortunatly, exceptions and exemptions are not exactly the same concepts.

Exceptions are user focused. They will be displayed to the users, one way or another: summary versus normalized metadata in the reading system. Their role is to warn impaired people on what they won't be able to do, on what will not work.

Exemptions are more legal oriented. They give additional information, i.e. the reasons why all/part of a publication cannot be made born accessible. These reasons probably do not interest the users. They interest certifiers/controlers, who will gain in analysis time. It will also help prevent wrong analysis from technicians, who do not know the constraints weighing on some publishing fields. In the educational field typically, when the full conformance to WCAG A/AA forces to give the answer to a question, that is a big problem! This is an important usecase of fundamental-alteration. And my point is that it is very partial/local to some content. It is not global to the entire publication.

You have to document the reasons why a publication is exempt separately for regulators according to the EAA, unless you're a microenterprise. The epub package document doesn't sound like a helpful place to duplicate it.

My understanding is that the point is to be able to inform user that this textbook has been made accessible except for video resources for which adding transcription would generate a fundamental alteration. So the user (main use case being a teacher) knows he can use the textbook with a wide range of student with disabilities, but he cannot use the video exercises with hearing impaired public.

The simple "exemption" could result in a user (teacher) not buying the book and erase the publisher's efforts to add accessibility to the best possible point.

This should be machine readable, not humanly written.

is to be able to inform user

But that again is what the summary is for. To make every possible failure point machine readable sounds like an exercise in metadata for metadata's sake. It places an even greater burden on vendors to have to turn the metadata into something readable, and forgets that in all other cases the user is left with some opaque-sounding metadata strings rather than something they can read.

But keep in mind that this property is being added to match what ONIX now allows. Given those records will likely be the primary source for obtaining the metadata in most cases, you should probably take this argument to them first. If they agree to subdivide the exemptions to account for all WCAG success criteria, we can always adapt this property to match them again later.

Precisely, there is no full equivalence between ONIX, and meta tags on exemption. ONIX is more powerfull.

ONIX FOR VENDORS
Here is the way I will provide information in ONIX about partial exemptions.

ProductFormFeatureType = 09
ProductFormFeatureValue = 00 | 76 | 77

<ProductFormFeature>
		<ProductFormFeatureType>09</ProductFormFeatureType>
		<ProductFormFeatureValue>00</ProductFormFeatureValue>
		<ProductFormFeatureDescription>This publication is born accessible, except for images / audio transcripts / video captions / video subtitles / video descriptions / interactive exercises</ProductFormFeatureDescription>
</ProductFormFeature>
<ProductFormFeature>
		<ProductFormFeatureType>09</ProductFormFeatureType>
		<ProductFormFeatureValue>76</ProductFormFeatureValue>
		<ProductFormFeatureDescription>Partial exemption forsome content only. Only (some) images / audio transcripts / video captions / video subtitles / video descriptions / interactive exercises are exempted from the European Accessibility Act compliance, because of disproportionate burden</ProductFormFeatureDescription>
</ProductFormFeature>
<ProductFormFeature>
		<ProductFormFeatureType>09</ProductFormFeatureType>
		<ProductFormFeatureValue>77</ProductFormFeatureValue>
		<ProductFormFeatureDescription>Partial exemption for some content only. Only (some) images / audio transcripts / video captions / video subtitles / video descriptions / interactive exercises are exempted from the European Accessibility Act compliance, because of fundamental alteration</ProductFormFeatureDescription>
</ProductFormFeature>

SCHEMA.ORG FOR READING SYSTEMS
meta @Property=schema:accessibilitySummary = This publication is born accessible, except for images / audio transcripts / video captions / video subtitles / video descriptions / interactive exercises
meta @Property=a11y:exemption = eaa-fundamental-alteration
meta @Property=a11y:exemption = eaa-disproportionate-burden

There is not equivalent for the ProductFormFeatureDescription in the meta tags, as normalized values are set in the text of the tag.
<meta property="a11y:exemption">eaa-fundamental-alteration</meta>

There is not equivalent for the ProductFormFeatureDescription in the meta tags

You're placing a lot of importance on mapping which exemption is claimed for each failure, but how often will two exemptions be claimed for the same publication? If the summary says some content fails, and you claim one exemption, you can infer the rest. If you claim two exemptions, the specifics of which exemption you want to claim for which failure aren't really going to add to users' understanding of the state of the publication. The inaccessible content remains inaccessible regardless.

But if you really want to annotate the exemption, you can attach a dcterms:description or schema:description to the exemption declaration. That's not adding anything epub can't already handle in the metadata.

I confirm that end users are not interested in information about exemptions, as I said myself. This information is interesting only for certifiers/controlers/institutional buyers who are not the end users.

I keep in mind your suggestion of using a schema:description, and attach it to the exemption metadata thanks to a refines attribute, if ever needed.

Thanks for your quick answers!

Publishers are not seeking for exemption. They try to produce born accessible products for everybody.
Everybody means impaired people who dramatically lack accessible textbooks today AND not impaired people, who still must be served in inclusive publishing.
Unfortunately, sometimes, not always, it happens to be true conflicts of interest between these two populations. Making some content accessible can lead to a fundamental alteration for UNimpaired people. We try to reduce this as much as possible, i.e. to make these exemptions as much LOCAL as possible, in order to avoid a GLOBAL exemption. And let it know.