Define EU conformance exemption metadata

[mattgarrish]

@gregoriopellegrino raised the need in the EU to identify publications that fall under one of the three exemptions from the accessibility requirements. ONIX is adding three new values to code list 196 to address this (75-77).

We're currently not aware of any existing metadata property that could be used to specify this information, so it sounds like we may need to add a new accessibility property.

It would be best to begin the discussion of what the property should be named and what values it should accept here, as we can add properties to the a11y: namespace without updating the specification (epubcheck won't complain).

Once we have a solid proposal in place, we can look at whether the new property can be added to the accessibility standard, but this may qualify as a class 4 change.

[mattgarrish]

@gregoriopellegrino can you post the new ONIX values so we can see what we're working with? I don't see them in the latest release, so I assume they're still proposals.

[gregoriopellegrino]

New codes proposed for ONIX issue 62 are:

• 75 EAA exception 1 – Micro-enterprises: Digital product falls under European Accessibility Act exception for Microenterprises (eg enterprises employing fewer than 10 people and with annual turnover or balance sheet total not exceeding €2 million). may carry details of the exception.
• 76 EAA exception 2 – Undue burden: Digital product falls under European Accessibility Act exception for Undue burden (the product may not have to comply if doing so would either change the nature of the product or service offered or if it would financially overburden the publisher).
• 77 EAA exception 3 – Substantial modification: Digital product falls under European Accessibility Act exception for Substantial modification (the product may not have to comply if doing so requires a substantial modification of the product or service).

[mattgarrish]

The really tough question here is how specific or generic do want this metadata to be. Will it be needed elsewhere?

If we want to make the property generic, a name like a11y:exception might be best, otherwise we could adapt the ONIX name to make it very specific (a11y:EAAexception).

The values for the EAA could be exactly what's already defined: "micro-enterprises", "undue burden", and "substantial modification".

One option would be to define a generic property that we eventually add to the vocabulary in the accessibility specification (this could be below class 3 if the spec itself doesn't require the metadata), and have a separate WG/CG note that specifies the values and how to use them for the EAA.

[mattgarrish]

Moved this issue to the epub-specs repository, as it seems like this is more appropriate for the WG than the CG given that it requests new conformance metadata.

[dazrand]

We should be careful on adding it to the EPUB metadata. One of the exceptions, Undue Burden, is a limited exception which has to be proven every so often (time scales are still in the air, but I believe 5 years is what some are proposing), but the other two could become irrelevant as well due to company growth or technological innovation. Since EPUBs tend to be static once they are released, this could pose a trust issue when circumstances change over time making the title no longer exempt from being accessible.

[clapierre]

@dazrand While I agree this could be an issue, we must also think that at that point in time when that EPUB was created and published it did have that exemption. Just like if an EPUB was GCA Certified in 2022 it was certified under WCAG 2.0 -AA, and now if that same EPUB was published it may be required to be at WCAG 2.1-AA.

Backlist titles will always be out-of-date with current laws and regulations, I don't think that should be a reason not to put in this metadata. It will be up to lawmakers to decide how to handle non-compliant older books, and those purchasing them will ultimately make the decision on which titles to buy. Do they buy a older non-compliant title, or switch publishers and find one who is compliant. Which may ultimately force the originally exempt publisher to remediate those titles if still relevant, or risk loosing sales.

[dazrand]

@clapierre While I agree some information is better than none, overtime this particular data could become misleading. At a minimum, for any of the three values we are talking about, there should be a date attribute added to indicate the year the determination was made. This would at least put the status in a date context for the user in the event there is a conflict between what current ONIX says and the EPUB says.

[clapierre]

Adding a date for when this exception was introduced might be a good idea, but if we try to enforce that I am worried that won't be an simple change as any MUST statements would make this a major undertaking and not something we are currently scoped to do. I would think that the date of publication should be enough wouldn't you think?

[dazrand]

The date of publication is very grey at times. I have seen publications with current publication dates for the paperback when the hardback was published 3 years ago. Add in eBooks and the publication dates can get much more murky. This really should focus on the date the exemption was granted or gained, which can differ from the publication date. Rather than a date attribute perhaps an refines value from dcterms to indicate the date.

[clapierre]

This could work but I defer to @mattgarrish we won't be able to mandate it but strongly recommend it be added when these exemptions are included.

[mattgarrish]

I would think that the date of publication should be enough wouldn't you think?

Don't forget that we already mention in the accessibility specification how to date assessments by attaching a dcterms:date to the dcterms:conformsTo statement.

Since the other pull request explains how to use "none" as the value when making an exception, mentioning to also date such statements in this note isn't unreasonable.

Making it a requirement to add a non-conformance statement and date it could make integrating this note into the accessibility standard in the future more difficult -- but explaining how to be exempt from the standard isn't really something we should be getting into in the specification (i.e., I'm not sure we go that next step).

I'm also not sure this is our problem. I can't expect the EAA would require publishers to revisit backlist titles when their circumstances change, but if they release a new version of the title then they may have to meet new requirements. In that case, I expect the metadata is going to be updated for multiple reasons, so removing the exemption doesn't seem burdensome. It seems like it would be helpful to know which version was produced with an exemption and which wasn't, though, if you encounter both versions.