Accessibility Metadata

[DavidMacDonald]

Current versions of SC and definitions

The proposal was changed from an SC to a edit to the optional components of a conformance claim. There is further discussion on the Daisy Issue list

• Conformance change for viewing | Conformance change for editing
• SC in full draft guideline

Short Name

Not an SC, a conformance criteria related to accessibility metadata

SC Text

Accessibility Metadata is provided which describes the accessibility characteristics of the content using an openly published vocabulary. 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.

Suggested Priority Level

Level AAA

Related Glossary additions or changes

• Accessibility Metadata. (Definition to come)
• Openly-published vocabulary (Definition to come)
• Machine readable description (Definition to come)

Principle: TBD

The purpose of this Success Criterion is to ensure that users can find accessible content and identify specific characteristics about the content that might meet their needs.

Metadata is especially important for publications, such as 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. (More here...)

Specific Benefits of Success Criterion 1.5.1

• Users who are blind will know if content will work with their screen reader.
• Users who are deaf would know whether there are captions or sign language on videos.
• more....

Justification and Evidence

Metadata was discussed in WCAG 2

With the emergence of digital publishing there is a great need for users to know about the ebook before they get it, so they won't be buying things that are inaccessible. It will help users who are blind choose a book without wasting time. (More here...)

Testability

This can be tested programmatically or functionally. In the code identify metatada elements. (More here...)

Related Resources

Resources are for information purposes only, no endorsement implied. http://pending.schema.org/. http://pending.schema.org/accessMode http://pending.schema.org/accessModeSufficient http://pending.schema.org/accessibilitySummary

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. (More here...)

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.

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.

Techniques

• (More here...)

Notes for working group

[jasonjgw]

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.

[DavidMacDonald]

@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

[chaals]

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.

[chaals]

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.

[madeleinerothberg]

@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.

[awkawk]

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.

[madeleinerothberg]

@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.

[jasonjgw]

The conformance section already specifies metadata as "recommended additional information" that should accompany a conformance claim. It refers to

"A machine-readable metadata version of the list of specific technologies that are relied upon" and "A machine-readable metadata version of the conformance claim".

It also recommends including "Information about any additional steps taken that go beyond the success criteria to enhance accessibility".

It does not refer to the use of established metadata vocabularies, or to the use of metadata to convey details of "steps taken that go beyond the success criteria". The conformance section could be improved in both of these respects.

Since metadata do nothing to enhance accessibility but only improve discoverability, any additional suggestions in regard to the use of metadata do not belong in the success criteria. However, there is an opportunity to improve what is already stated in the Conformance section. I also think this section is logically the right place to discuss metadata.

[avneeshsingh]

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..

[awkawk]

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.

[awkawk]

@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?

[cstrobbe]

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.

[Ryladog]

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.

[Ryladog]

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

[madeleinerothberg]

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.

[jasonjgw]

WCAG 2 already provides for metadata to be used to specify conformance claims. I think a proposal should be put forward to create a vocabulary for doing this which could be well integrated into current metadata standrads. I don’t know whether schema.org is the right venue for this, but if we started working on it now, we could have it in place in time for the publication of WCAG 2.1, then cite it as a non-normativ reference or in the techniques documents.

---

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

---

[DavidMacDonald]

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."

[jasonjgw]

From: David MacDonald [mailto:notifications@github.com] Sent: Friday, December 9, 2016 11:53 AM

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."

[Jason] I think this is good text for a success criterion, but (as indicated earlier in the discussion), I object to adding a metadata requirement to the success criteria.

I propose the following alternative. In the Conformance section, after “A machine-readable metadata version of the conformance claim”, add a further list item:

“Machine-readable metadata describing any additional steps taken that go beyond the success criteria to enhance accessibility.”

Note that the language is taken from one of the earlier list items, but currently there is no metadata suggestion which parallels the “additional steps” item. My proposal is to add it.

---

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

---

[mattgarrish]

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.

[jasonjgw]

No, in fact, the documenting of other steps precisely would be the accessibility metadata which makes assertions about accessibility-relevant properties of the content that go beyond what is in the conformance claim. It is not metadata about the existence of other metadata. Since discoverability does not improve accessibility, it does not belong in the success criteria, but it clearly belongs in the Conformance section where it guides content authors in documenting what they have achieved in order that users can find it (or have it prioritized in search results).

The Conformance section already advises authors to provide machine-readable metadata of the conformance claim; my proposal adds further advice that they include metadata about other accessibility-relevant properties which are not associated with conformance requirements. In this respect, it parallels the advice given in the earlier item regarding steps that go beyond what is required by the success criteria.

If you think that the proposed wording is confusing, we could clarify it to say “Machine-readable metadata declaring other characteristics of the content that enhance its accessibility”.

---

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

---

[madeleinerothberg]

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.

[jasonjgw]

We could write a vocabulary of user-identifiable terms with which to make a WCAG conformance claim. There’s no requirement anywhere that conformance claims have to be specified in terms of the numbering scheme used in WCAG success criteria. WCAG 2.0 already asks for machine-readable metadata documenting conformance; I think the metadata community could do much more to make this easier. At a minimum, the author should be able to assert conformance at levels A, AA and AAA, but a vocabulary that addresses individual success criteria would be more comprehensive.

For the Silver design process, I think there should be very careful thought given to whether to require metadata in conformance claims. The EPUB accessibility specification achieves this by creating a separate category of conformance for the metadata, encouraging accessibility-relevant features to be reported even if there is no substantive conformance to WCAG-based requirements at Level A.

My recommended strategy regarding this issue would be as follows. For WCAG 2.1, strengthen the text currently included in the Conformance section. Provide an agreed upon metadata vocabulary with which to claim WCAG conformance (as already envisaged in WCAG 2.0).

For Silver, consider what role metadata should play in the conformance arrangements. The entire design of Silver is open; it isn’t a limited extension to an existing specification, so there’s good opportunity to be creative in deciding how to frame it within the conformance scheme.

---

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

---

[lseeman]

Hi Madeleine We also need to be creating meta data and user setting for the needs for people with cognitive disabilities. We will be doing that soon so we should coordinate the work

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Fri, 09 Dec 2016 23:48:57 +0200 Madeleine Rothberg<notifications@github.com> wrote ----

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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[madeleinerothberg]

@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

[clapierre]

Hello Lisa, @lseemanhttps://github.com/lseeman Benetech and the Diagram Center are also very interested in this as well. keeping both Madeleine and myself looped in would be great!

Thanks EOM

Charles LaPierre Technical Lead, DIAGRAM and Born Accessible E-mail: charlesl@benetech.orgmailto:charlesl@benetech.org Twitter: @CLaPierreA11Y Skype: charles_lapierre Phone: 650-600-3301

On Dec 12, 2016, at 7:33 AM, Madeleine Rothberg notifications@github.com<mailto:notifications@github.com> wrote:

@lseemanhttps://github.com/lseeman

[jasonjgw]

I’m also very interested in metadata regarding access features for people with learning/cognitive disabilities.

---

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

---

[joshueoconnor]

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

[mbgower]

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.

[lseeman]

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

[joshueoconnor]

@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?

[DavidMacDonald]

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

[DavidMacDonald]

This SC and discussion is reopened and can continue.