There are several concerns with this proposal: (1) it doesn't make the content in question more "robust", where robustness refers in WCAG to backward and forward compatibility and to compatibility with assistive technologies. (2) It does not improve the accessibility of the content; it only makes more accessible content easier to distinguish from less accessible content (e.g., when searching). (3) It's unclear which accessibility characteristics need to be reported in order for this proposed criterion to be met. (4) As a Level AAA proposal, it's likely to be ignored in practice. Worse, there's a strong incentive for authors to implement levels A and AA before even looking at this proposed SC, so anything meeting this SC would most likely satisfy levels A and AA already, thus making specific metadata less useful - the content is already highly accessible.

As I've argued under Issue 16, I think this proposal should be treated as an amendment to or as a clarification of the metadata suggestions in the Conformance section, and it should focus on conformance reporting as its primary purpose.

To be clear, this is an objection to the proposal in its present form.

@jasonjgw I changed the principle to be determined. I believe the epub team are fine with a AAA because there is still a certain amount of development that is being done on the schema, and this is a start just to legitimize and provide a platform to launch the discussion "metadata is required by Level AAA WCAG". I support that effort and I think all agree it could not be required at a higher level at this point. The other option is a best practice, which will unlikely get any working group attention during this intense time of creating SCs for WCAG 2.1

As benefits to accessibility metadata:

1. It helps determine, a priori, whether a particular resource is useful for a particular user or set of users.
2. It may point to alternative versions of a resource, enabling discovery of a resource or set of parallel resources that meet the needs of a given set of users.

It seems to me that a best practice, maybe even a part of the Success Criterion, is to point to known alternative versions as well as identify the accessibility status of the resource directly described.

A suggestion for the wording:

Provide programmatically determinable description of the accessibility of content, using a freely available metadata vocabulary.

I don't think any of these terms need a new glossary entry - which is a goal.

@jasonjgw Actually, I think the fact that authors who use the metadata have likely already met AA is a feature, not a bug. One goal of the metadata is to make it easier for users to locate the accessible needles in the haystack of web content. So if page authors who have created accessible materials use metadata to say so, search engines can get users to accessible resources that they might not otherwise find.

As far as Principles go, is there precedent for "cross-cutting" SCs? Metadata could be about any (all?) of the principles and doesn't fall neatly into one.

Part of the problem that I'm having with this language is that it is doing the opposite of what we've tried to do in WCAG - we have strived to create SC that identify the end-user problem and require that the content addresses it using a technological solution of their choice. This one is saying "use metadata" which is the technical solution, but doesn't identify the user problem crisply.

@chaals - your wording leads to the problem side better "Provide programmatically determinable description of the accessibility of content" but then seems to suggest a technique "using a freely available metadata vocabulary".

To require metadata, we will need to be very specific about what the user needs are so authors can map the needs to the specific metadata that they elect to use. If the SC is effectively "use metadata" we can expect that people will ignore it, and we will have a very hard time even writing success techniques for it.

@awkawk There is a specific metadata vocabulary available from Schema.org, and that will be the primary technique. We are not mentioning it in the SC because there could be other kinds of metadata that would be acceptable techniques. The use of "freely available" or "openly published" is intended to require that you not just make up your own, since interoperability will be easier if everyone uses the same vocabulary, or a small set of vocabularies. What wording might better capture that?

To make it a more a user-centered SC, maybe this would help:
Make it easier for users to find your accessible content by providing . . .

One drawback to that language is that it implies only positive statements are needed. We are also interested in people reporting inaccessible content, because it can warn users not to bother downloading a resource.

Will the following rephrasing resolve the issue of positive indications:
Make it easier for users to find the content that satisfies their accessibility requirements by providing..

We haven't typically done "freely available" or "openly published" because the "accessibility supported" language covers the issue of whether something actually works in practice. So actually, if you want to create the Rothberg metadata schema you may, and if there is sufficient accessibility support for it, you can claim conformance on the basis of that. In practice, that isn't too likely.

I do believe that we will be looking to address the accessibility supported concept in Silver, but will not be able to change that in WCAG 2.1.

@madeleinerothberg /@avneeshsingh - I think that wording is a step in the right direction.

To @jasonjgw's point - perhaps if this is covered under the conformance criteria all we need is conformance techniques?

After reading through the comments, here is my attempt at an alternative formulation.
Proposal for SC text:
If alternative versions of the web page are available, a mechanism is available to locate the alternative version(s) of the content based on machine-readable accessibility metadata.
Note to the SC: A human readable summary of the accessibility metadata may also be provided. (However, I wonder if the more appropriate way to deal with this is a recommended technique.)

Definition: Machine-readable accessibility metadata: A machine-readable description of the accessibility characteristics of a web page using an openly published vocabulary. [Would "features" be better? Stating that something does not meet SC x.y.z sounds more like a characteristic than a feature to me.]
Note to the definition: Accessibility data may include machine-readable references (especially URLs) to accessible alternatives.

However, since Jason pointed out that it does not make content more accessible, I wonder if this should be an SC at all instead of an optional part of the conformance claim.

Christophe,

This kind of Accessibility Metadata is mostly used for finding alternative content for a component of a page (generally not the whole page), such as a video. The metadata would provide pointers to say video descriptions in several different languages.

Another use is the metadata that tells search engine and their users, more about the specific Accessibility features of the resource (web page, or digital book).

So I am not sure your suggestion would be helpful in general.

Andrew,

You said:"Part of the problem that I'm having with this language is that it is doing the opposite of what we've tried to do in WCAG - we have strived to create SC that identify the end-user problem and require that the content addresses it using a technological solution of their choice. This one is saying "use metadata" which is the technical solution, but doesn't identify the user problem crisply."

Accessibility Metadata actually can identify end-user problems, and solutions, and a user can know in advance if a resource (web page, web app or digital book) has the specific Accessibility features that a user is looking for - to help them determine, if it is worth going there (or downloading) or not.

Metadata can crisply identify specific needed features users want OR that users want to avoid.....when used properly

While metadata can be used to point to alternative versions, the metadata currently in Schema.org does not do that. It describes the current resource but does not include pointers to other resources. Other sets of metadata including IMS Access for All include that concept, but they aren't aimed at HTML implementation.

What about this?

"Accessibility supported characteristics of the content can be programmatically discovered. At a minimum this is a machine readable description either on the page or referenced from the set of pages to which it applies. A human readable summary may also be provided."

So there would be metadata to indicate that metadata has been added, but there would be no specific direction to include accessibility metadata, since all that is asked is to document other steps? (This is getting very meta!)

I'm not sure how this makes the metadata any more likely to be included than now, given that reporting is optional and this would be a further optional step that would require digging into supplementary documentation to discover more about.

Isn't there an argument for robustness that having machine-readable metadata improves search engine processing, which facilitates new and better search interfaces now and into the future? I accept that the metadata doesn't improve the accessibility of the content itself, but it seems plain enough that a search engine is an agent that retrieves content, indexes it and presents it to users in digestible form to aid their navigation. Ignoring their needs ignores a critical part of the web infrastructure, IMHO.

The accessibility features we are talking about documenting are not additional steps beyond conformance. They identify which particular kinds of features are available. You could perhaps map them to specific WCAG SCs. The premise of the metadata work is that users don't know what features they want by the WCAG numeric references, but they do know the names of features they want, like captions or image descriptions. Thus this approach to documenting accessibility is based on user-understandable terms as much as possible.

@lseeman
Hi Lisa,
We would love to have more information on user settings for people with cognitive disabilities. Please do let me know what is in progress. I'm at madeleine_rothberg @ wgbh.org

Assigned to @Ryladog https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1

From discussions, I believe this candidate SC is primarily intended to address reporting of alternative content, and almost exclusively as it relates to Time-based media. As stated in the Principle section, the motivator for this appears to have been packaged publications (i.e. ePub) that wish to indicate supported content, much like a DVD package might indicate that it contains language tracks and subtitles.

I would suggest that a new technique could be written which would achieve this end without resorting to a SC. An example would be "Creating Metadata that indicates the presence and nature of media alternatives" That could appear under any of the 1.2 Time-based Media SC.

If we discover other metadata that has roughly equivalent value (i.e., indicating the presence of MATHML or other alternatives for symbols) those could be handled through a similar technique (in 1.1.1 Non-text content).

Most other reporting for the state of accessibility is handled at a macro level through VPATs, and that seems like the appropriate mechanism.

can we merge with part of #46 that seas that supported apis are defined in metadata.
Also I am happy to make a vobablery for support by the time we get to CR

@Ryladog Can we get a status update on this one - do you think this is close to having something we can survey? Or do you need more time?

Closing this issue and have opened pull request #142 and have moved most recent version of SC text there.

This SC and discussion is reopened and can continue.