Approaches for elevating EPUB accessibility to new versions of WCAG

[avneeshsingh]

As discussed in Accessibility task force calls, migrating EPUB accessibility specifications to WCAG 2.1/2.2 is important. The main question is how should we do it.

Option 1: Hard wire EPUB Accessibility 1.1 with WCAG 2.1 Advantage: that It is simple and straight forward, no confusions. If publishers find it difficult to conform to WCAG 2.1 then they can conform to EPUB Accessibility 1.0 which conforms to WCAG 2.0. Disadvantage: WCAG 2.2 will be released soon, and in such a case will will need to revise EPUB Accessibility as WCAG progress.

Option 2: Allow EPUB Accessibility 1.1 to refer to different versions of WCAG (version 2.0 onwards). i.e. Publication can conform either to EPUB accessibility 1.1 (WCAG 2.0), EPUB Accessibility 1.1 (WCAG 2.1), and also EPUB Accessibility 1.1 (WCAG 2.2) Advantage: High flexibility and future proof approach. Disadvantage: Reporting will become highly complex.

Option 3: EPUB Accessibility 1.1 has date-less or version-less reference to WCAG. i.e. it refers to the latest version of WCAG. Right now it is version 2.1, in future we would have version 2.2, 3.0 etc. Advantage: Conceptually simple and future proof. Disadvantage: Some segments of publishing industry may feel that it is very aggressive approach, because publishing industry moves at a slower pace than web. It is possible that most of the industry remains at EPUb Accessibility 1.0, and some highly progressive publishers move to version 1.1. Moreover there is a practical problem, publications are not updated like web pages, which means that reporting will still need to include reference to WCAG version met by the publication at the time of production.

Thoughts are welcome, especially from the publishers and supply chain actors who need to deal with complexities of conformance reporting.

[gregoriopellegrino]

Option 3 does not convince me for the following reason: EPUBs are normally "static" documents that are not updated after being published (except on rare occasions). So a WCAG update could make an EPUB made years earlier and compliant with the WCAG of the time no longer conform to the new requirements.

Taking into account that in Europe publishing accessible EPUBs will become law, I think publishers do not want to have bad surprises years after publishing an ebook.

[mattgarrish]

Option 1a might be that we require conformance to 2.1 or its successor versions. This would avoid the problem @gregoriopellegrino has pointed out of content not being fully forwards compatible. WCAG is supposed to remain backwards compatible, so content that conforms to a later standard will still also conform to 2.1

To tie it in to #1455, if you conform to a later version of WCAG, you can specify that in a second conformsTo. This would give publishers the ability to make an accurate claim without having to wait on a revised standard to move up to each new version of WCAG.

[gregoriopellegrino]

WCAG is supposed to remain backwards compatible, so content that conforms to a later standard will still also conform to 2.1

But not the other way around, right? A publication that complies with WCAG 2.1 may not comply with WCAG 2.2.

To tie it in to #1455, if you conform to a later version of WCAG, you can specify that in a second conformsTo. This would give publishers the ability to make an accurate claim without having to wait on a revised standard to move up to each new version of WCAG.

Yes, we need to figure out how to describe this information with ONIX as well. That is why I contacted EditEUR.

[mattgarrish]

But not the other way around, right?

Right, we can't have the wcag version be ambiguous.

If someone moves ahead of the 2.1 requirement to start conforming to 2.2 or 2.3, we know those publications are still conformant with 2.1 so would remain conformant with the epub specification. Stating conformance to a newer version of wcag wouldn't be required, but I'm sure publishers would want to do it to show they're staying up to date.

The opposite isn't necessarily true -- content that conforms to 2.1 might or might not conform to 2.2 or 2.3 depending on what changes. In this case, reporting wcag conformance becomes a necessity in all cases, as only stating conformance to the epub specification would be ambiguous.

[rdeltour]

I'm in favor of option 3, it's the best way for EPUB Accessibility to stay up-to-date with the latest accessibility standards. It would also be the best incentive for publishers to stay up-to-date on latest accessibility practices.

Forward compatibility of static publications is a bit of a pipe dream anyway. EPUB itself refers to the living HTML standard, which can break conformance pretty much anytime.

A publication can always declare (in metadata) conformance to the version of EPUB Accessibility in use at the time it was created. Wouldn't that be sufficient for most legal frameworks? (I'm not an expert on this point).

[mattgarrish]

Wouldn't that be sufficient for most legal frameworks?

I don't think it would work, since there isn't a common conformance requirement or update path for everyone. Some people won't have to, or want to, migrate just because a new release is put out. But in this model they're immediately non-conforming as soon as a new REC is published unless they do migrate (i.e., there's no standard anymore to which they could conform at their specific requirements).

It generally boils down to a question of whether we want to be the ones pushing the bar ever higher or slowly raising the floor. We can lose publishers if we're too aggressive, but users can lose out if our standards move up too slowly.

[clapierre]

In light of all this I am either in favor of Option 1 or 2. Once we have 1.1 an official TR then creating a 1.2 to conform to WCAG 2.2 wouldn't be very difficult.

I do like Option 2 thou, but am unclear on why this would be an issue on reporting? What Reports? Most folks won't know the difference between WCAG 2.0 / 2.1 or 2.2 only those who need to know that could find out that information from the metadata say a school district which must for legal reasons have WCAG 2.1 compliance would be interested in knowing if this EPUB complies with that.

I would like to know which option makes it easier for ONIX thou as that should be considered.

[rdeltour]

I'm in favor of option 3 (…) Wouldn't that be sufficient for most legal frameworks?

I don't think it would work, since there isn't a common conformance requirement or update path for everyone. Some people won't have to, or want to, migrate just because a new release is put out. But in this model they're immediately non-conforming as soon as a new REC is published unless they do migrate (i.e., there's no standard anymore to which they could conform at their specific requirements).

Reading Avneesh’s opening comment again, what I'm thinking may look more like option 2:

• the spec refers by default to the latest version of WCAG (to stay up-to-date)
• it allows conformance to older versions of WCAG (starting from the current version, 2.1), if reported in metadata.

That way we avoid publications becoming non-conforming as soon as a new REC is published.

It generally boils down to a question of whether we want to be the ones pushing the bar ever higher or slowly raising the floor. We can lose publishers if we're too aggressive, but users can lose out if our standards move up too slowly.

Given the reasonable pace of WCAG development, I'm not too concerned of being too aggressive. Before becoming a rec, WCAG goes through many cycles of reviews, public comments, etc. It gives time for people to get up-to-date.

In any case, this is all quite subtle. With option 1, the spec is stuck in WCAG 2.1 but publications can use WCAG 2.1+. With option 2/3, the spec is based on WCAG 2.1+ but publications can use earlier WCAG versions. My take is that if the spec doesn't encourage people to use the most recent, then people will simply not use it.

[mattgarrish]

My take is that if the spec doesn't encourage people to use the most recent, then people will simply not use it.

Except that both approaches end up with the same recommendation in this proposal. The difference is not setting a minimum we expect. The options we're discussing in normative prose become:

"EPUB Publications MUST meet WCAG 2.1 but SHOULD meet the latest version (of WCAG 2)."

vs.

"EPUB Publications SHOULD meet the latest version of WCAG but MAY meet any earlier version."

We'll also need to consider how "undated" we want to get when these wordings could pull WCAG 3 and/or WCAG 1 into consideration.

[mattgarrish]

Trying to synthesize the discussions today about keeping WCAG 2.0 level A as the baseline and explaining why we recommend the latest version and level, what do people think about rewriting section 3.3.1 along these lines:

An EPUB Publication has to meet to the following requirements to conform to this specification:

• It MUST meet the requirements of WCAG 2.0 [WCAG20] but it is strongly RECOMMENDED that it conform to the latest recommended version [WCAG].

• It MUST meet the requirements of Level A but it is strongly RECOMMENDED that it meet Level AA [WCAG].

The baseline requirement for WCAG 2.0 Level A is to allow Authors flexibility to report conformance at whatever threshold they are required to meet (e.g., by local and national laws, or by a procurer or distributor of their content).

Ideally, Authors should strive to conform to the latest version of WCAG as that standard is continually evolving to improve access for users. As web technologies change and improve, and awareness of conditions that impede access evolve, new requirements are added. Meeting the requirements of the latest version is the best way to ensure that EPUB Publications are accessible to the greatest number of users. Meeting the requirements of older versions, while still helpful, can result in a less optimal reading experience.

Similarly, Level AA conformance is often cited as the benchmark for accessibility in legal frameworks and policies. The reason for this is that it provides the greatest range of improvements that can realistically be implemented (Authors are encouraged to try and meet the AAA requirements if they can, but fully conforming at AAA is typically not possible). Only meeting level A requires compromises for various user groups that can again result in a less optimal reading experience.

[llemeurfr]

I like the approach.

Only remark, a typo (bold + underlined below)

(Authors are encouraged to try and meet the AAA requirements if they can, but fully conforming at AAA is typically not realistic)

[wareid]

Sorry to have missed the meeting today, had a conflict.

Considering that almost every major piece of legislation in this space requires at least WCAG 2.0 AA, why should we not aim for that? I haven't checked the minutes yet, so apologies if I'm missing something that was already discussed.

My concern with stating a publication MUST be A, but we recommend AA, is just conflicting with local laws, and potentially putting publishers in a tough spot when legislation is instated in their region, if they remediated their backlist to A, then find out it needs to be AA, they're in for trouble.

[llemeurfr]

@wareid has a good point.

Something I'd like to be sure about the end result of this discussion: we all need a clear notion of boolean accessibility, with a boolean value (this EPUB is accessible "yes/no"). This is what will allow people checking the evolution of the % of accessible EPUBs in different countries.

Therefore we need to be able to state that EPUBs conforming to this specification are Accessible, EPUBs not conforming to this specification are NOT Accessible. Do people agree with this? I know that this is an over-simplification but in the non-expert world, such simplification is needed.

[mattgarrish]

Considering that almost every major piece of legislation in this space requires at least WCAG 2.0 AA

@avneeshsingh made the point that we shouldn't penalize people from regions where there aren't specific laws and where accessibility may still be in its infancy. We still want to grow adoption.

We also talked about whether we are trying to be the gatekeepers telling people what they have to meet or if we should be accommodating what each region requires. We run the risk of being ignored if we impose different standards on people, or at least of aggravating producers.

WCAG doesn't require you to meet a level but defers to other authorities to spell out the specific requirements. By doing the same, we increase the flexibility of the specification.

[mattgarrish]

Only remark, a typo

Thanks, I've fixed the original comment, too.

[mattgarrish]

EPUBs not conforming to this specification are NOT Accessible

That's kind of a hornet's nest to get into.

For one, not meeting wcag doesn't necessarily make a publication inaccessible to a specific user group, which is why we have the section on optimized publications in the spec.

If a publication hasn't been checked, it's also not fair to say it's inaccessible. We just don't know.

I don't know that a publisher would ever put out a publication that acknowledges it isn't accessible, either, so it probably will never be clear what number of publications definitively fail accessibility.

But I think you can still get a useful overall measure of adoption by looking at the total number of publications marked as conforming vs the total number published in any year. So long as that number is growing we're on the right track.

[iherman]

The issue was discussed in a meeting on 2021-01-14

• no resolutions were taken

View the transcript

### 1. Approaches for elevating EPUB accessibility to new versions of WCAG _See github issue [#1459](https://github.com/w3c/epub-specs/issues/1459)._ **Avneesh Singh:** there are 3 options. … option 1: Hard wire EPUB Accessibility 1.1 with WCAG 2.1 (or whatever the current version is). … if publisher wants to use a lower version of WCAG, they will use the older version of a11y spec. … option 2: Allow EPUB Accessibility 1.1 to refer to different versions of WCAG (version 2.0 onwards).. … but downside is that this is more complex. … option 3: EPUB Accessibility 1.1 has date-less or version-less reference to WCAG (i.e. the latest version always). … this is approach that we take towards compatibility with HTML. … but accessibility generally moves at a slower pace. … this also makes it mandatory for authors to comply with the latest WCAG. … also, epubs aren't updated like webpages, once published, they aren't necessarily updated. **Matt Garrish:** there were also intermediate options discussed in the issue. … like make minimum 2.1, but recommend that publishers use the current WCAG. … i.e. set a floor beyond which you can't go, but encourage use of latest. … romain also suggested that we encourage use of latest, but allow compliance with older versions as long as they disclose which version they are using. **Tzviya Siegman:** i like matt’s and romain’s proposal for their greater flexibility. **Cristina Mussinelli:** can we get more explanation of option 3?. **Matthew Chan:** it would be an undated version, essentially as soon as 2.2 comes out, publishers would have to comply with 2.2 to comply with a11y spec. **Cristina Mussinelli:** normally once an epub is released, publishers treat it like a released product. Static, not requiring updates.. … also, with EUAA requiring that epubs comply with spec, tying spec to most up-to-date WCAG places a huge burden on them. … i prefer the solution where publishers just declare which accessibility version they are using. … it would be very complex for publishers to identify and update which titles they have to update. **Avneesh Singh:** option 3 sounds like it is not the favorite of anyone. **Ben Schroeter:** +1 to Cristina's comment. … there is always going to be lag between when a new standard is announced and when the publisher can begin to react to the new standard. … it can be slow. **Avneesh Singh:** and it seems like no one likes Option 1, hardwiring spec to WCAG version 2.1. … we could update the spec to future versions of WCAG under option 1, but then there is the additional overhead of doing this. **Cristina Mussinelli:** can we wait to resolve on which approach to take until the next call?. … we will then have better understanding of what the EUAA requires of the spec. **Avneesh Singh:** we're not making any final decision now. We'll just post the results of a vote on github as a proposal for people to comment on. **George Kerscher:** so we're proposing that we set a floor of WCAG 2.1, but encourage that publishers use the latest WCAG?. **Matt Garrish:** yeah, and then Romain suggested that we not have a hard floor, and instead just subject it to an obligation to disclose the version used. … and then also, when we refer to the latest version of WCAG, does that refer only to WCAG 2.x, or also 3+?. **Tzviya Siegman:** I think we can leave it as "latest version", but we inside this group will know that we are referring to 2.x only. 3+ is not coming along that quickly. **Avneesh Singh:** so, do we want to establish a floor at WCAG 2.1?. **Ben Schroeter:** publishers have existing titles that align with 2.0, so are we saying that those are not accessible?. **Avneesh Singh:** those would be accessible per spec 1.0, but not spec 1.1. … in summary, we are proposing option 2: referring to the latest WCAG 2.x, but providing the option to publishers to use earlier versions (up to 2.0). **Matt Garrish:** regarding the question of when publishers should "re-check" their connect for accessibility, maybe our guidance should be that publishers should only do that if they re-release their content. … but maybe it would be better to leave that to legislation to be decided. **George Kerscher:** so will this be backwards compatible?. … so that older publications would conform to the spec without being touched?. **Avneesh Singh:** yes. **Charles LaPierre:** if we wanted to explore option 3 (i.e. versionless), couldn't that just be tied to the version of WCAG that was current as of the publication date?. … so that years later, that publication would still be spec compliant because of its earlier publication date. **George Kerscher:** that would make it very complicated for users to know what to expect in terms of a11y. It would require calculation as to which WCAG was current at the time of publishing.... **Matt Garrish:** for publications, we have to accept that they are created according to a spec at a given point in time. … unlike other web content. **Charles LaPierre:** I like option 2 anyway, was just an idea.

[avneeshsingh]

Overall it looks good Matt. I think that we can oriented the following sentence from opposite direction:

"The baseline requirement for WCAG 2.0 Level A is to allow Authors flexibility to report conformance at whatever threshold they are required to meet (e.g., by local and national laws, or by a procurer or distributor of their content)."

We can rephrase it as: The baseline requirement for WCAG 2.0 Level A is to allow Authors flexibility and backward compatibility for the old content. However it can result in a less optimal reading experience, and lower compatibility with the legal frameworks of many countries.

You can improve the language as you like.

[mattgarrish]

Thanks @avneeshsingh . I've opened #1469 so we can continue to discuss wording changes there.

I rewrote the first few paragraphs after the two bullet requirements to emphasize 2.0 Level A is generally not a great target to meet: https://raw.githack.com/w3c/epub-specs/a11y-11/conformance-issues/epub33/a11y/#sec-wcag-conf

[einmanncombo]

Hi there,

from my point of view a relevant part about WCAG is missing: full WCAG compliance can only be confirmed by a manual testing procedure as several WCAG parts refer to editorial issues. So only a human can say after such a testing procedure for sure, to which standard the files complies. Just writing something into a file, may lead to a huge amount of only machine validated, but not accessible files. Furthermore: In reality a huge amount of files exists that violate parts of WCAG (e.g. bad contrast, forced by corporate design, historical issues), but are really good accessible in all other parts. If WCAG 2.1 or whatever will be the minimum all these files will be incompliant. This would be not goof practice to track a "live or die approach". E.g. EU legislation at least tolerates such issues under certain circumstances.

Therefore: there is not the one and only solution for that. But i could make sense to split up all issues:

1. Does the file claim to be accessible: "yes/no"
2. Which main guideline it refers to: free text e.g. "WCAG" (there is more in the world than WCAG, a fixed list would be better, to avoid errors, but the standard should not be static)
3. Which version does it claim to be: e.g. "2.1"
4. Which level does it claim to be: e.g. "AA"
5. And may be more, like What the files test by a machine; a human, any exclusions…

Best, Klaas Posselt

[llemeurfr]

Just a note: because of WCAG 2.1 Reflow section,, it appears that no Fixed-layout ebook, even perfectly optimized for accessibility (with Media-Overlay ..), can reach WGAC AA level.

[mattgarrish]

it appears that no Fixed-layout ebook ... can reach WGAC AA level

It's certainly going to make things hard, but can't responsive design principles help for a lot of books? Not every fixed layout publication requires content to stay positioned where it is.

I wonder if there might be a use for alternate style tags here, too (e.g., a "reflow" styling that can be applied when the content is zoomed).

Similarly, we might want to look at whether this is something reading systems can implement on their own. PDFs get a pass if the user agent can reflow the text into a single column when zoomed, so I don't see why the same wouldn't apply to EPUBs if this were a common enough feature that low vision readers could depend on it.

even perfectly optimized for accessibility (with Media-Overlay ..)

The reflow requirement is for users with low vision, and media overlays aren't a universal solution in this case. It's an old complaint about WCAG that it focuses too much on the needs of users who are blind and assumes the solutions are equally valid for low vision.

[llemeurfr]

@mattgarrish, looking at the ecosystem of authoring systems in the field (InDesign, PubCoder, BookCreator ...), it will be a looong time before responsive ebooks are a reality.

I'm starting thinking that having a too tight integration between the current requirements of WCAG 2 and EPUB accessibility has drawbacks. In particular the accessibility of very simple ebooks cannot be checked 100% automatically and now FLX books cannot be tagged as AA accessible. It is creating friction, where we all want to move up tremendously the number of Accessible ebooks on the market.

[llemeurfr]

On another level, if we are thinking about how to integrate new versions of WCAG, we cannot totally put aside WCAG 3, which replaces A to AAA with Bronze to Silver and is based on a rating system, quite different from the WCAG 2 set of requirements.

[avneeshsingh]

We have discussed most of these issues in Jan 14 task force call. It may be helpful to go through it:

https://www.w3.org/publishing/groups/epub-wg/Meetings/Minutes/2021-01-14-epub-a11y

[mattgarrish]

I'm starting thinking that having a too tight integration between the current requirements of WCAG 2 and EPUB accessibility has drawbacks.

We're ultimately not the ones enforcing what content has to conform to, though. The proposal that Avneesh points to in the minutes is that we only mandate the most basic conformance (2.0 Level A) to provide flexibility for whatever is required in each region or what each publisher is capable of achieving.

That will allow publishers to move at their own pace, at least where laws don't mandate otherwise. It also means we don't break from the formally recognized standard and open ourselves to criticism that we've just lowered the bar to allow less accessible content through.

WCAG 3 is slightly more interesting than 2 in that it allows for some failures without an entire publication failing and also looks at conformance across the spectrum of different user cases. We can also potentially define accessibility for publication directly instead of adapting what is done for the web. But it's still a long way from becoming a reality.

[GeorgeKerscher]

We also require that the metadata specifies what level of WCAG and the version that was reached. Plus we do recommend double A.