Reporting accessibility conformance

[mattgarrish]

The old IDPF conformance URLs have to be updated for the next release and we also need to figure out how to ensure a more stable reporting method going forward.

The base URL to use for the epub accessibility specification should be fairly straightforward as we'll have a versioned /TR path to use this time (no need for a dated specification).

The complexity comes in also having to report the WCAG version and level, assuming we are allowing flexibility in conformance. We should figure out how important this information is to break out. Do vendors care about the specifics of conformance, for example, or only that content conforms to the accessibility standard?

In a world where the details aren't that critical, one option would be to drop the WCAG conformance level from the conformsTo URL entirely so only the accessibility specification URL is used. The WCAG version and level could be required in the accessibility summary, for example, so users can still understand the quality. For example:

<link rel="dcterms:conformsTo" href="https://www.w3.org/TR/epub-a11y-11/"/>
<meta property="schema:accessibilitySummary">... This publication conforms to WCAG 2.1 Level AA. ... </meta>

One problem with this approach, however, is that the information won't be easily parseable by tools like Ace. But these tools may also always assume conformance to the latest version (making them account for variances between releases could prove a maintenance headache).

Alternatively, we could require (or recommend) a second conformsTo field that specifies the WCAG version:

<link rel="dcterms:conformsTo" href="https://www.w3.org/TR/epub-a11y-11/"/>
<link rel="dcterms:conformsTo" href="https://www.w3.org/TR/WCAG21/"/>

The problem remains here is that WCAG doesn't have URLs for each conformance level, so unless we require AA conformance we're still going to be missing information. We could require that context in the summary, though.

Looking at the Dublin Core definitions again, we might also simply consider using a natural language descriptor for WCAG conformance. The vocabulary now says this:

Creators of non-RDF metadata can use the terms in contexts such as XML, JSON, UML, or relational databases by disregarding both the global identifier and the formal implications of the RDF-specific aspects of term definitions. Such users can take domain, range, subproperty, and subclass relations as usage suggestions and focus on the natural-language text of definitions, usage notes, and examples.

https://dublincore.org/specifications/dublin-core/dcmi-terms/#section-1

This sounds to me like the rigidity of dcterms properties for linked data has been relaxed. In that case, we could require authors to follow a pattern like "WCAG 2.X Level AA":

<link rel="dcterms:conformsTo" href="https://www.w3.org/TR/epub-a11y-11/"/>
<meta property="dcterms:conformsTo">WCAG 2.1 Level AA</meta>

We could also take this one step further and incorporate everything in one common pattern like:

<meta property="dcterms:conformsTo">EPUB Accessibility 1.1 + WCAG 2.1 Level AA</meta>

That's as far as my thought experiments have taken me with this, at any rate. Other ideas welcome.

/cc @avneeshsingh @clapierre @GeorgeKerscher

[murata2makoto]

@mattgarrish

The technical committee of the Japanese DAISY consortium plans to introduce three sets of metadata. It is natural to expect conformance reporting dedicated to these sets. I would thus like to have an extensible mechanism. The use of the href attribute is certainly extensible.

The problem remains here is that WCAG doesn't have URLs for each conformance level

I think that such URLs should be introduced. Very important things on the Web should have names.

[clapierre]

To further complicate things ONIX code page 196 looks like its hard coded to the accessibility 1.0 Specification at either A / AA

https://ns.editeur.org/onix/en/196

196	02	EPUB Accessibility Specification 1.0 A Conforms with the requirements of EPUB Accessibility Spec 1.0 and WCAG level A. may carry a URL linking to a compliance report or certification provided by an independent third party certifier. In the absence of a URL, conformance with the requirements of the Accessibility Specification is self-certified by the publisher

196	03	EPUB Accessibility Specification 1.0 AA Conforms with the requirements of EPUB Accessibility Spec 1.0 and WCAG level AA. may carry a URL linking to a compliance report or certification provided by an independent third party certifier. In the absence of a URL, conformance with the requirements of the Accessibility Specification is self-certified by the publisher

[mattgarrish]

To further complicate things ONIX code page 196 looks like its hard coded to the accessibility 1.0 Specification at either A / AA

We don't really need to solve that, as those codes would remain valid for whatever content already uses them. The question would become do they want to add new codes every time there's an update or should a field more aligned with conformsTo be better choice (i.e., in which the identifier can be copied).

If we want to avoid having to revise the document every time there's a new WCAG release, we need flexibility in stating conformance. But if we want precision in terms of what was actually conformed to, we also need a pattern that is easily replicated and updated. The layered approach of accessibility doesn't make this an easy task.

If we require AA support, then the two-field approach is probably the best:

<link rel="dcterms:conformsTo" href="https://www.w3.org/TR/epub-a11y-11/"/>
<link rel="dcterms:conformsTo" href="https://www.w3.org/TR/WCAG21/"/>

(Conforming to AAA is generally unrealistic so we don't have to account for it.)

Another thing we could do is say that by default 2.1 conformance is required, in which case the second conformsTo property isn't required. But if you conform to a lesser version (if we allow that) then you must specify the second field and if you conform to a newer version you should specify it (it wouldn't be required because backwards compatibility of wcag would make conformance with 2.1 always true).

[clapierre]

I see so we would duplicate the conformsTo

1. for the EPUB specification and the
2. for what WCAG version/level was obtained.

This works well also because some publishers have their own a11y conformance level internally they may want to add as well

Example from one of our GCA™ Publishers( @RachelComerford ): <meta property="dcterms:conformsTo">Macmillan Learning Flat Accessible ePub Specification V4.0</meta>

[mattgarrish]

I think that such URLs should be introduced.

I've opened an issue to have identifiers added so we can link to them: https://github.com/w3c/wcag/issues/1575

Beyond this issue, it would help with the crosslinking to the WCAG definitions, as right now all our links on specific levels can only go to the conformance level section.

[gregoriopellegrino]

I will write to EditEUR to get their opinion.

[gregoriopellegrino]

Feedback from EditEUR:

I think it would depend on the degree of change between v1.0 and any future version. A simple update that doesn’t add (too much) to the requirements of meeting the new standard would not require a new ONIX code, whereas a more significant change where e-books that clearly meet v1.0 do not meet significant new requirements of the standard would require new codes.

As an alternative to adding two new codes each time you revise the EPUB Accessibility spec, we could introduce a mechanism to carry a second URL which identifies the version of the Accessibility standard and WCAG.

In terms of what you’re discussing on Github, a single URL that specifies the version of the EPUB Accessibility Spec (1.0, 1.1, 2.0 or whatever), the WCAG version used within the Spec (2.1, 2.2 etc) and the level (A, AA) of WCAG would be ideal, provided there’s some expectation that future versions of the standard will use a similar URL-based versioning mechanism.

[iherman]

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

• no resolutions were taken

View the transcript

### 3. Reporting conformance _See github issue [#1455](https://github.com/w3c/epub-specs/issues/1455)._ **Matt Garrish:** there are a number of different ways we could approach conformance. … one way, 2 conformance statements, 1 for spec, and 1 for WCAG. … another way, move away from tying this to URLs, and just use text subject to a common pattern. … but we probably can't resolve on this until we first resolve the questions of WCAG versions and levels. **Avneesh Singh:** in the issue, there was talk about harmonizing ONIX and our conformance statements, this is a good thing. **Charles LaPierre:** both approaches above make sense to me. … one thing, right now vendors like vitalsource are looking in the metadata for a specific string. … and multiple conforms to statements confused their systems. **Avneesh Singh:** we'll have to keep backwards compatibility in mind for that reason. **George Kerscher:** can you clarify the pattern we would use? what that would mean?. **Matt Garrish:** yeah, so we could specify an order for spec number, WCAG version and levels, so that the text conformance statement could still be machine readable.

[avneeshsingh]

@gregoriopellegrino any idea how two conformsto urls be used in ONIX (one for EPUB accessibility version and other for WCAG)?

Single URL makes it somewhat simpler if we want to map it to different metadata formats.

[gregoriopellegrino]

Some months ago I asked to EditEUR:

In the W3C we are working on a new version of the EPUB Accessibility Guidelines...

In short: at the moment codes 2 and 3 in code list 196 refer to EPUB Accessibility Guidelines 1.0, what will happen when the new version is released? Will more codes be added? And so on?

This is their reply:

I think it would depend on the degree of change between v1.0 and any future version. A simple update that doesn’t add (too much) to the requirements of meeting the new standard would not require a new ONIX code, whereas a more significant change where e-books that clearly meet v1.0 do not meet significant new requirements of the standard would require new codes.

As an alternative to adding two new codes each time you revise the EPUB Accessibility spec, we could introduce a mechanism to carry a second URL which identifies the version of the Accessibility standard and WCAG.

In terms of what you’re discussing on Github, a single URL that specifies the version of the EPUB Accessibility Spec (1.0, 1.1, 2.0 or whatever), the WCAG version used within the Spec (2.1, 2.2 etc) and the level (A, AA) of WCAG would be ideal, provided there’s some expectation that future versions of the standard will use a similar URL-based versioning mechanism.

[mattgarrish]

Given our flexibility of reporting and that you could conform to many different versions of WCAG under a single accessibility version, it's more than just two new URLs for every new version. There are at least six combinations for 1.1 -- WCAG 2.0 or 2.1 and Level A, AA or AAA. (And more permutations to come with 2.2, etc.)

The most viable options at this point are either patterned text strings:

• EPUB Accessibility 1.1 + WCAG 2.0 Level A
• EPUB Accessibility 1.1 + WCAG 2.0 Level AA
• EPUB Accessibility 1.1 + WCAG 2.0 Level AAA
• EPUB Accessibility 1.1 + WCAG 2.1 Level A
• EPUB Accessibility 1.1 + WCAG 2.1 Level AA
• EPUB Accessibility 1.1 + WCAG 2.1 Level AAA

Or a similar URL pattern like

• https://www.w3.org/TR/epub-a11y-11/?wcag=2.0&level=A
• https://www.w3.org/TR/epub-a11y-11/?wcag=2.0&level=AA
• etc.

WCAG doesn't define a means of identifying the level in the URL, and the request I made to add IDs won't be available until 2.2 is released (and will never be available for the earlier versions). That likely makes separating the URLs the least viable option we have.

[iherman]

The issue was discussed in a meeting on 2021-02-25

List of resolutions:

• Resolution No. 1: single field with three strings EPUB acessibility + WCAG version + level

View the transcript

### 1. Reporting accessibility conformance _See github issue [#1455](https://github.com/w3c/epub-specs/issues/1455)._ **Avneesh Singh:** mgarrish if you could please provide an overview? **Matt Garrish:** basically, what should we do with the IDPF urls we have now, specific to WCAG2? … given the flexibility that we have around which version and level of WCAG, i don't know that we can do a URL approach to this … we can either come up with a new pattern of URL where you can plug-in the values of your version and level … or we do a text field following a strict pattern … it might ultimately come down to whether ONIX requires a URL, or if they can take text strings **Avneesh Singh:** it looks obvious that having a single URL `conformsto` value is the way to go … or, we could have a text string that has epub a11y version, wcag version, and level **Matt Garrish:** the problem is that we allow so many variations in 1.1 … any url that represents would involve a bunch of parameters … a patterned text string would be easier for humans to work with **Charles LaPierre:** first, we want to make sure that whatever we do is backwards compatibility with the current version … for the old epubs … second, for the future, the silver TF just presented a future version of WCAG that replaces the A, AA level with bronze, silver, gold … and rn vitalsource is looking for a particular string, because publishers are putting in their own custom `conformsto` values **Gregorio Pellegrino:** from ONIX point of view, they said that they are okay with adding new values … but it is uncommon in ONIX to just take text as a value … if we do ask them to ask code values, they said that they only update twice a year … so there may be a delay in updating **Avneesh Singh:** there was also a comment that a url could be provided in ONIX? **Gregorio Pellegrino:** normally in ONIX there is a closed dictionary of values that can be assigned - i.e. a codelist … you could make it a free text value, which could take a URL … but if you are using an automatic solution for parsing ONIX, this could be complicated by free text … for example, in ONIX, you can use URLs to point to supplemental resources … but not usually as data references … so are we talking about using a single URL, with various parameters? **Avneesh Singh:** yes … there is also the question of customized accessibility spec, e.g. an optimized publication … these would also require a customized url **Gregorio Pellegrino:** using a text field to store a URL also presents issues with being able to validate **Matt Garrish:** i'm not sure we can make our solution compatibility with 1.0 … because the URLs would have to be to W3C pages instead of the old IDPF … if we are concerned that people are already setup to look for URLs, that could be a consideration to continue using a URL based system instead of going with a text string **Gregorio Pellegrino:** so to summarize, we have 3 pieces of data, a11y version, wcag version, and level? So maybe we can have 3 ONIX fields to track this... **Tzviya Siegman:** i understand that vitalsource is already setup to use urls, but especially as WCAG advances, this is going to get more and more complicated … 3.0 is coming, and we don't know which version of WCAG people are going to be using … the number of URLs that we'd have to keep track of might not be that manageable … a text string may be easier to maintain **Avneesh Singh:** to clarify, the URL could be reference to a11y spec, and then WCAG could be identified separately **Matt Garrish:** also, these `conformsto` values are for machines to process, not necessarily for humans to read. Don't forget that people can also put information about a11y in accessibility summary > *Gregorio Pellegrino:* it's like namespace in XML, you always get 404 :) **Charles LaPierre:** point about validation, if a particular URL references a page that doesn't exist, that could be flagged by an automatic validator, right? **Matt Garrish:** the URLs would be de-referenced, they would just be for machines to parse to extract a11y metadata **George Kerscher:** does this meet the publisher's desire to put their own `conformsto` string in their publications? Is this repeatable? … makoto also mentioned in issue tracker that he needs flexibility to add different properties in there **Matt Garrish:** there's no limitation to the number of `conformsto` > **Proposed resolution: Single URL for conformance, EPUB accessibility specs string + WCAG version and level** *(Avneesh Singh)* > *Gregorio Pellegrino:* +1 to Charles **Charles LaPierre:** since you can have multiple `conformsto`, why not have the 3 as separate `conformsto` statements? **Gregorio Pellegrino:** i like this, for me it is more readable … also, this allows us to expose real URLs to end users, which will lead to read documents **Matt Garrish:** i'm not sure that would work, because there is no real webpage for each level of conformance … no level A page, level AA page, etc. **Tzviya Siegman:** and its not always so easy to say "i conform to AA" … a lot of books partially conform to AA, missing one thing … that sort of data sometimes is not so black and white **Charles LaPierre:** mgarrish, would we put a refines on the `conformsto` WCAG version? **Matt Garrish:** right... but then we'd have to come up with a new property, with a new set of values **Tzviya Siegman:** refines is going away eventually **Matt Garrish:** to me, even two pieces seems complicated to ask people to put in their publications **Charles LaPierre:** even with vitalsource, who are parsing this, they are seeing maybe 5 different conformsto in some books … and they don't know which one to look at for wcag version, which for wcag level, etc. **George Kerscher:** does the proposed approach work with ONIX, assuming that we can add new codes? **Gregorio Pellegrino:** not sure, I can check with Graham … they would prefer to have 3 fields in ONIX, but that doesn't necessarily change our spec, we can still have one single URL in our publications **Ben Schroeter:** we need to think about how `conformsto` will actually be used … e.g. if we actually expect people to go to that URL, or just a way to designate a11y metadata … are we making it too hard, on ourselves, on publishers, by being so particular about the level? > *Bill Kasdorf:* I could imagine a publisher saying `@conformsto="VPAT"` **Ben Schroeter:** when they could just put that info, if they want, into the accessibility summary? **Avneesh Singh:** confromsto is for distributors and retailers … and different states will have different a11y legislation that require conformance data **Ben Schroeter:** and we have to give consideration to alternative specifications **Gregorio Pellegrino:** i think that from an end user point of view, knowing that a publication conforms to A vs AA makes a difference … conformsto works towards retailers being able to filter publications by this level **Matt Garrish:** so, these things are identifiers, they're not meant to be surfaced to users necessarily … a machine is going to parse it before an end user ever sees it > *Bill Kasdorf:* +1 to Matt **Matt Garrish:** our solution should be useful to machines - and either URL or formatted text string meets this criteria > *Charles LaPierre:* +1 as well to Matt **Avneesh Singh:** if we are recommended the triple of data in a single URL, that doesn't prevent anyone from putting a different URL to their own spec, etc. … we are just saying that if you are using EPUB a11y, then please use this URL, if not, they are free to use some other value **George Kerscher:** can you explain "3 strings in a URL"? **Avneesh Singh:** let's say "single field, with 3 strings" then > **Proposed resolution: single field with three strings EPUB acessibility + WCAG version + level** *(Avneesh Singh)* > *George Kerscher:* +1 > *Gregorio Pellegrino:* 0 **Avneesh Singh:** gpellegrino to please update ONIX people **Gregorio Pellegrino:** yes, okay > *Ben Schroeter:* 0 > *Matt Garrish:* So: EPUB Accessibility 1.1 + WCAG 2.0 Level AA? **Bill Kasdorf:** are we going to be providing specific vocabulary for those three things? **Avneesh Singh:** yes **Charles LaPierre:** I thought we started off with the URL approach... i'm not as confident with the single text string, with 3 parts … then we have to explain which delimiters to use between the three parts … with a URL and parameters, this is already done for us, there's only the one way to do it **Avneesh Singh:** is this a serious problem, do you think? **Charles LaPierre:** ...not sure **Matt Garrish:** we could also enumerate the 6 currently possible strings, with instructions about how to increment the WCAG number … so its not necessarily that problematic **Charles LaPierre:** the idea of providing some pre-formatted examples is a good direction … with some precautions put in place for future proofing against WCAG 3 **Matt Garrish:** right, and we can put language in there about replacing A and AA with bronze, silver, etc. > *Charles LaPierre:* +1 **Avneesh Singh:** CharlesL, please solicit feedback from distributors/retailers currently parsing `conformsto` **Charles LaPierre:** okay > ***Resolution #1: single field with three strings EPUB acessibility + WCAG version + level***

[gregoriopellegrino]

I wrote to EditEUR

[iherman]

Adding a comment that came up in an internal discussion. Does this type of approach raise internationalization issues? I.e., the identification is made through a text field which, in fact, is not really a text, but a very English oriented identification, with concatenation based on space and '+' characters. This may be misleading for some (think of languages that do not have a notion of spaces between words...).

I am not sure whether this is a real issue, but maybe it merits some thoughts.

(Using URL-s instead is, in this respect, cleaner.)

Cc @r12a @xfq

[iherman]

The issue was discussed in a meeting on 2021-03-04

• no resolutions were taken

View the transcript

### 6. Reporting accessibility conformance _See github issue [#1455](https://github.com/w3c/epub-specs/issues/1455)._ **Wendy Reid:** there was a comment about whether the resolved solution raises i18n issues **Matt Garrish:** we'll wait to see what the i18n folks say about it **Wendy Reid:** ivan mentioned that not all languages use spaces, so our patterned string, which does, might be problematic **Matt Garrish:** hopefully people are just copying and pasting this, instead of trying to type it in **Wendy Reid:** if people are using production tools, this is just going to be inserted programmatically … but we need answers from i18n before we can resolve this question

[iherman]

@r12a @xfq is there an issue here (see https://github.com/w3c/epub-specs/issues/1455#issuecomment-789617935)? If not, this issue should be closed...

[xfq]

Adding a comment that came up in an internal discussion. Does this type of approach raise internationalization issues? I.e., the identification is made through a text field which, in fact, is not really a text, but a very English oriented identification, with concatenation based on space and '+' characters. This may be misleading for some (think of languages that do not have a notion of spaces between words...).

If it's just a string that is not a natural language data value, I don't think it is a problem, but I think it is better to make it look like an identifier when designing this kind of string, maybe something like EPUB_A11Y_11_WCAG_21_AA.

[mattgarrish]

maybe something like EPUB_A11Y_11_WCAG_21_AA

I like this idea. It's not as cumbersome as a URL but less potentially confusing than purely text strings.

Perhaps we could mix hyphens and underscores for slightly more clarity that there are two distinct specifications?

So maybe:

EPUB-A11Y-11_WCAG-21-AA

or

EPUB_A11Y_11-WCAG_21_AA

[iherman]

maybe something like EPUB_A11Y_11_WCAG_21_AA

I like this idea. It's not as cumbersome as a URL but less potentially confusing than purely text strings.

Perhaps we could mix hyphens and underscores for slightly more clarity that there are two distinct specifications?

So maybe:

EPUB-A11Y-11_WCAG-21-AA

or

EPUB_A11Y_11-WCAG_21_AA

+1. I am slightly more in favour of the former of these two, but we should not spend too much time on this:-)

[mattgarrish]

I am slightly more in favour of the former of these two

Agree. It's more common to use underscores for joining segments and hyphens within them in my experience.

[clapierre]

+1 to this approach as well, we already found some old conformance links pointing to the W3C web submission document, to an old version of the IDPF and both upper/lowercases. This will help mitigate these types of errors as we see below:

(Thanks to VitalSource for providing the following data on published EPUBs with the following dcterms:conformsTo metadata) http://www.idpf.org/epub/a11y/accessibility-20160801.html#wcag-AA
http://www.idpf.org/epub/a11y/accessibility-20160801.html#wcag-aa/
http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-a http://www.idpf.org/epub/a11y/accessibility-20170105.html#wcag-aa
https://www.w3.org/Submission/epub-a11y

So could we then for older versions like these above, we would have the following metadata right?

EPUB-A11Y-10_WCAG-20-A EPUB-A11Y-10_WCAG-20-AA which would reference the 1.0 Spec and WCAG 2.0

[mattgarrish]

So could we then for older versions like these above, we would have the following metadata right?

EPUB-A11Y-10_WCAG-20-A EPUB-A11Y-10_WCAG-20-AA

We can't change the 1.0 specification, so these wouldn't be valid to either specification. All we can do is try and avoid the same pitfall of linking the identifier to an organization.

Better to move people on to 1.1 as soon as we can to avoid proliferating the IDPF identifiers any more than they have been. Other than removing the alt text exemption, content being produced that conforms to 1.0 should immediately conform to one of:

• EPUB-A11Y-11_WCAG-20-A
• EPUB-A11Y-11_WCAG-20-AA

Moving publishers to WCAG-21 can happen more gradually.

[mattgarrish]

Closing this specific issue, though, as the changes are now integrated. We can refine any details as we go.