Request to consider inclusion of accessibility metadata

[mattgarrish]

At the end of the joint call we had about digital publication issues on October 25, the digital publishing side were asked to raise the issue of the inclusion of discovery metadata for further discussion. To kick that discussion off, I'd like to provide some background.

Schema.org currently contains a set of four properties under CreativeWork that allow the expression of metadata about the accessible characteristics of a web page: accessibilityFeature, accessibilityHazard, accessibilityAPI and accessibilityControl. An additional three properties are currently pending inclusion: (accessMode](https://schema.org/accessMode), accessModeSufficient and accessibilitySummary. These properties are primarily based on the IMS Global Access for All metadata standard, and the original set of properties were submitted by IMS.

I won't try to describe all these properties in detail, but, beyond their definitions in schema.org, more information about them is available in the Web Schemas accessibility wiki. The pending properties are documented in a wiki. More information about the use of these properties in EPUB is also available in the Discovery sections of the accessibility specification and techniques.

The referenced EPUB documents should make clear the importance that we place on this metadata for publications, especially those that are packaged and distributed through third parties. The metadata allows users to discover more detailed information about publications without having to consume them first, as it can be processed by any search engine, whether in a proprietary bookstore or on the open web.

In a large and heterogeneous Web, helping users with accessibility needs locate accessible content is an important way to support the use of the Web by people with disabilities, and the same developers who are following WCAG guidelines to improve the accessibility of their Web content are likely to be the most motivated to apply accessibility metadata.

In summary, given the benefits of descriptive documents, we'd like to propose the inclusion of accessibility metadata for consideration in WCAG 2.1.

[jasonjgw]

I think the best way to support metadata in WCAG would be as an optional means of reporting conformance. This would require the use of standard metadata properties for asserting conformance to WCAG at a specific level. It may also be desirable to allow for reporting of success criteria satisfied at the next level beyond that at which conformance is claimed.

I don't think use cases in which non-conforming content that nevertheless has some accessibility-related features reports these facts in metadata are likely to gain much uptake, for legal reasons. The problem is that such metadata amount to an assertion (indeed an admission) that the content does not conform to WCAG, and this has legal implications in some contexts. So requiring such reporting is altogether out of the question, in my view, and should not be pursued.

[mattgarrish]

Agreed, I don't think the failing case that EPUB addresses is applicable here, and I wouldn't see it as a recommendation to include even if content fails, as we've done. The request is more a question of whether the additional discoverability value for users searching for content is sufficiently beneficial. And it may be the case that not all the properties have value for fully-conforming content.

In discussions we had before adding this proposal, we also acknowledged that the importance that we've given to the metadata in the EPUB specification might be too strong, given that we address failing content, as we don't want authors inserting copied metadata just because they have to (i.e., addition could well be an AAA criteria).

I certainly appreciate your position on having metadata more specific to wcag conformance, Jason. I'd like to hope we could have both, but this is the kind of discussion we were hoping to generate.

[jasonjgw]

If a requirement is sufficiently important to guide a user's searching
activity and therefore to be expressed in metadata, then surely it is also
valuable enough to be included in WCAG success criteria, even if only at Level
AAA.

Thus, I can't think of a good case for describing an accessibility-relevant
property in metadata, but deciding not to have a corresponding WCAG success
criterion to address it. I may be wrong, of course, but if a given feature
isn't worth requiring in WCAG even at Level AAA, then it's hard to make a
strong argument for declaring it. After all, if it made that much of a
difference to accessibility, it ought to be relevant to conformance at some
level.

Thus I think conformance reporting is the proper scope of metadata so far as
WCAG is concerned. This could include declaring which technologies are relied
upon for purposes of conformance as well.

[mattgarrish]

Maybe I'm misunderstanding, but the accessibilityFeature property allows that now. Most of the values reflect WCAG success criteria, like alternative text, extended descriptions, captions, transcripts, tables of contents, etc. The list could always be expanded to be more comprehensive, if there are significant gaps.

There are some values that aren't pertinent to WCAG, of course, but not everything the property can address has to be in scope.

[madeleinerothberg]

It is true that WCAG conformance reporting is an important use case in some settings. But in many years of metadata development efforts aimed at directly helping consumers who wish to locate accessible materials, while we considered creating WCAG point-by-point conformance metadata, we felt it would be useless to consumers who don't know which checkpoint they need by its number; they just know they need captions (or descriptions, or color contrast, or etc.). A UI could be built on top of the metadata to allow translation between checkpoint numbers and human-readable terms, but that isn't currently how schema.org metadata is used. The terms used in the markup are exposed directly. For that reason, the groups creating the metadata have consistently decided to use a vocabulary of common terms for accessibility features. Adding this metadata as a recommended practice in WCAG will encourage creation of the ecosystem needed to support consumers in locating materials they can use.

[jasonjgw]

In WCAG 2.0, under "Optional components of a conformance claim", we have:
"* A machine-readable metadata version of the list of specific technologies
that are relied upon.

• A machine-readable metadata version of the conformance
  claim."

It would be possible to strengthen this to a required rather than an optional
component of the conformance claim. It would also be possible to specify a
prescribed metadata format or vocabulary to be used.

A vocabulary with two properties: version of the guidelines, and conformance
level (A, AA and AAA) would actually cover many of the important cases. How
much value is there to users in asserting partial conformance (e.g., level A
plus specified success criteria, or level AA plus specified success criteria)?
I don't know the answer, but it's an interesting question. It may be that for
most people, just having a conformance level is enough to identify (or give
higher search ranking to) the right content.

At the moment, there's no requirement in WCAG to declare conformance at all.
Do we want to make it harder to do by requiring it to include machine-readable
metadata? Do we want to set in concrete a specific metadata format or
vocabulary? Are there other proposals in play?

[joshueoconnor]

Surveyed: https://www.w3.org/2002/09/wbs/35422/ACT_DPUB_Review_Nov_2016/

[DavidMacDonald]

This Success criteria is being written in Issue #82

[awkawk]

Closing as replaced by issue 82