Please keep Boris in the cc: field when replying to this thread.
We feel the best strategy for accessibility information in metadata would
be to align with the Web Content Accessibility Guidelines (WCAG2)
standard, a W3C recommendation which is officially defined at
http://www.w3.org/TR/WCAG/ . There's also a nice summary at
WCAG defines 12 guidelines in 4 categories: content must be (1)
Perceivable, (2) Operable, (3) Understandable, and (4) Robust. Under
these 12 guidelines are a set of success criteria. Here is an example:
> 1.4.3 Contrast (Minimum): The visual presentation of text and images of
> text has a contrast ratio of at least 4.5:1, except for the following:
> (Level AA)
> Large Text: Large-scale text and images of large-scale text have a
> contrast ratio of at least 3:1;
> Incidental: Text or images of text that are part of an inactive
> user interface component, that are pure decoration, that are not
> visible to anyone, or that are part of a picture that contains
> significant other visual content, have no contrast requirement.
> Logotypes: Text that is part of a logo or brand name has no minimum
> contrast requirement.
As you can see, the sucess criteria are pretty detailed and measurable.
The recommendation says "WCAG 2.0 success criteria are written as
testable statements that are not technology-specific". However, it would
not be trivial for a search engine to simply scan web pages to see if
they meet them - you can only test it if you know which text or images
are logos, which are decoration, and which are important user interface
elements. Testing tools are available, but human judgment is required as
part of the process. The WCAG site has considerable additional text
around each of these criteria - how they apply to various technologies,
lists of techniques for meeting them, etc. Our suggestion is that if a
site author has tested their site (or some pages of it) for compliance
with these criteria, they could indicate that fact though a metadata
Note that WCAG also defines a coarse-grained compliance "level": A, AA,
or AAA. Each of the success criteria are part of one of those levels (AA
for the example above). We considered a metadata field simply stating
which level the web page meets, but that would not provide nearly as much
helpful information to a potential user of the page, and would not
provide any way for site owners to show that they had met, say, all but
one of the AA-level criteria. An additional metadata field could be
added with the overall compliance level - but that is probably not
necessary. Given a list of specific criteria that have been tested and
passed, it is trivial for a program to determine which level that
represents, or for an authoring tool to automatically attach the list of
criteria given the compliance level.
The success criteria are technology-neutral in the sense that they do not
talk about specific things you should or should not do with, say,
required for a page may also be critical information. Someone browsing
with an iPad may want to avoid pages that depend on Flash; someone whose
"depending on" a technology from simply "using" it -- it is possible (and
available, but still work when it is turned off.
To inform people of this we recommend a "technologies required" field.
An additional "technologies used" field could also be defined, but it is
less important to know, and perhaps easier to automatically determine. A
compromise might be listing "technologies recommended" - the ones you
should have to get the full experience as designed. The range of legal
values of these remains TBD , but it should be some official list so that
we don't have confusion between different abbreviations. The "Internet
http://en.wikipedia.org/wiki/Internet_media_type) might be appropriate,
though it's possible that there are technologies that we would want to
list that don't correspond to a media type.
The metadata will amount to a statement of conformance to the WCAG, so
it's important to look at the definition that the recommendation provides
of a "conformance claim": (see
> if a conformance claim is made, then the conformance claim must include
> the following information:
> Date of the claim
> Guidelines title, version and URI "Web Content Accessibility
> Guidelines 2.0 at http://www.w3.org/TR/2008/REC-WCAG20-20081211/"
> Conformance level satisfied: (Level A, AA or AAA)
> A concise description of the Web pages, such as a list of URIs for
> which the claim is made, including whether subdomains are
> included in the claim.
> Note 1: The Web pages may be described by list or by an expression
> that describes all of the URIs included in the claim.
> Note 2: Web-based products that do not have a URI prior to
> installation on the customer's Web site may have a statement that
> the product would conform when installed.
> A list of the Web content technologies relied upon.
So our list of metadata fields will try to follow this:
1. date of testing seems useful. Pages change, and the information about
accessibility might be out of date.
2. the WCAG guidelines also do get updated, so the link to the
date-coded recommendation URL seems appropriate.
3. as argued above, conformance level is implicit in the list of
4. if we're attaching metadata to a web page, the scope would presumably
be just that page.
5. list of technologies will be explicitly included.
It also seems like a "says who?" field would be useful - what person, or
organization is making the claim of conformance? To whom do you complain
if is no longer true?
Putting it all together, we get this list of suggested metadata fields:
1. wcagVersion: (URL)
2. wcagCriteria: (list of strings of the form #.#.# [alternatively, the
short names or URLs could be used to identify criteria])
eg: 1.1.1, 1.2.1, 1.2.2
3. wcagVerificationDate: (optional?, date)
4. wcagVerificationBy: (optional, person or organization)
5. technologiesRequired: (list of technologies from vocabulary TBD)
eg: text/html, application/x-shockwave-flash
6. technologiesRecommended: (list of technologies from from vocabulary
presumably, technologies that are required don't have to be listed
I wanted to point out a couple of things which are in my mind still open questions here:
1. How should the technologies required/technologies recommended be listed? Is Internet Media Type appropriate, or should it be a schema.org maintained list, or a plain text field?
2. Are list-valued properties as I suggested good to use, or should they be written as properties that connect to a single "criterion" or "technology required", and then the property would appear as many times as needed? I'm looking back at the discussion of the "teachesCompetencies" and related properties, which connects to a single Competency, and wondering if the same strategy should be used here (more verbose but perhaps more easily machine-processed?)
With a schema.org hat on here, ... having this stuff expressible using
schema.org-based markup would be great; but having schema.org maintain
and publish the actual enumerated list of values is something we want
to avoid. We'll try to make structures that allow enumerations
maintained elsewhere to be plugged in...
Peter Pinch at WGBH forwarded the messages about accessibility metadata to
me and I joined the LRMI group so I can participate in the discussion. I'm
with the WGBH National Center for Accessible Media and have been working
on accessibility metadata for learning resources for many years.
I propose that LRMI and schema.org use IMS Access for All v3 (AfA3) for
accessibility metadata. I explain below why I think it will be more useful
to this particular project than a set of metadata based on WCAG 2. A draft
of AfA3 is available (with free registration) in the IMS public forums at:
The complete public draft of v3 will be available shortly. It has a few
specific changes from the draft available now, but has not changed in
Providing metadata about accessibility evaluations against WCAG is
important for compliance processes and for developers who need to resolve
accessibility problems, but I don't think it is useful to individual
users. A user would need to have a list of which checkpoints they do and
do not care about in order to evaluate the information. Devices, operating
systems, and assistive technology currently in use are also important. IMS
and W3C participants have been working on a framework that would allow
automated use of AfA, WCAG, and hardware/software information to adjust
the discovery and display of resources based on this full technical
picture. We do not expect end users to carry out this process themselves.
My understanding of the schema.org effort is to provide functionality
similar to the chocolate chip cookie recipe example. This approach
emphasizes a list of facets that are intuitive to users and that they can
easily match to their own needs. AfA is a better match for this model than
AfA metadata lists the kinds of media contained in a resource, much like
the ingredients in a recipe. Is there audio here? Visuals? Text? These
"access modes" are the basic information of AfA and allow users to select
resources that contain the access modes they can use. In addition, AfA
records what adaptations are available for the access modes in the
resource, such as captions for audio or text descriptions for visuals.
There are also metadata fields that indicate the ability to interact
accessibly with a resource by keyboard or assistive technology and the
degree to which the resource's display can be customized with standard
visual changes for text. In addition, important for educational searchers,
AfA can indicate if the resource has adaptations that cover the same
material with reduced or enriched complexity.
An example of AfA in use can be seen in Teachers' Domain at:
Most resources display AfA metadata about adaptations; this is probably
not how schema.org would present the data but will give you some ideas.
You can also see the personalization features that are possible using the
matching AfA user preferences: create a free account and then visit "My
Profile" and set some accessibility preferences. Now search for your
favorite science topic ("turtle" works well) to see the feedback.
I am happy to provide more information or answer any questions.
Begin forwarded message:
On Nov 21, 9:33 am, Madeleine Rothberg <madeleine_rothb...@wgbh.org>
> Hello LRMI folks,
> Peter Pinch at WGBH forwarded the messages about accessibility metadata to
> me and I joined the LRMI group so I can participate in the discussion. I'm
> with the WGBH National Center for Accessible Media and have been working
> on accessibility metadata for learning resources for many years.
> I propose that LRMI and schema.org use IMS Access for All v3 (AfA3) for
> accessibility metadata. I explain below why I think it will be more useful
> to this particular project than a set of metadata based on WCAG 2. A draft
> of AfA3 is available (with free registration) in the IMS public forums at:http://www.imsglobal.org/community/forum/messageview.cfm?catid=88&thr...
> Begin forwarded message:
> >From: Greg Grossmeier <g...@creativecommons.org>
> >Date: November 16, 2011 2:50:21 PM EST
> >To: LRMI <lr...@googlegroups.com>, LRMI TWG <lrmi...@googlegroups.com>
> >Cc: "bgoldow...@cast.org" <bgoldow...@cast.org>
> >Subject: Accessibility Metadata
> >Reply-To: "lr...@googlegroups.com" <lr...@googlegroups.com>
> >The below is the proposal sent to me from Boris Goldowsky from CAST to
> >extend schema.org with accessibility metadata. I only made some minor
> >formatting changes.
> >Please keep Boris in the cc: field when replying to this thread.
> >We feel the best strategy for accessibility information in metadata would
> >be to align with the Web Content Accessibility Guidelines (WCAG2)
> >standard, a W3C recommendation which is officially defined at
> >http://www.w3.org/TR/WCAG/. There's also a nice summary at
> >> Guidelines 2.0 athttp://www.w3.org/TR/2008/REC-WCAG20-20081211/"
> >> Conformance level satisfied: (Level A, AA or AAA)
> >> A concise description of the Web pages, such as a list of URIs for
> >> which the claim is made, including whether subdomains are
> >> included in the claim.
> >> Note 1: The Web pages may be described by list or by an expression
> >> that describes all of the URIs included in the claim.
> >> Note 2: Web-based products that do not have a URI prior to
> >> installation on the customer's Web site may have a statement that
> >> the product would conform when installed.
> >> A list of the Web content technologies relied upon.
> >So our list of metadata fields will try to follow this:
> >1. date of testing seems useful. Pages change, and the information about
> > accessibility might be out of date.
> >2. the WCAG guidelines also do get updated, so the link to the
> > date-coded recommendation URL seems appropriate.
> >3. as argued above, conformance level is implicit in the list of
> > criteria met
> >4. if we're attaching metadata to a web page, the scope would presumably
> read more »
We have a use case for Access for All posted to LRMI, but it is under the
NSDL category, because that is another project currently using AfA.
Personalized Access to NSDL (PAN) Portal
We also have evaluation data for AfA as used in Teachers' Domain. We had a
group of teachers of middle school students with disabilities plan lessons
using Teachers' Domain without AfA and then with it. Their lesson planning
time (search and discovery and determining suitability for their students)
was reduced to about a quarter the time when they had AfA metadata.
There is a Core application profile of AfA metadata that has 11 metadata
elements. There are six additional elements in the full model, four of
which I would recommend for this project. I'm not sure what size of
element set is considered ideal for LRMI, so I don't know if this is a
large number of elements. Most instances would not use all of the elements
since they have different purposes.
In the WCAG proposal, all information about the accessibility of the page
is contained in one element:
> 2. wcagCriteria: (list of strings of the form #.#.# [alternatively, the
>short names or URLs could be used to identify criteria]) eg: > 1.1.1,
I could write a use case for a resource teacher looking at that list of
wcagCriteria and deciding which resources met the needs of a particular
student, but it would be a rare teacher who has the deep technical
knowledge required to parse a list of WCAG checkpoints and know what they
mean, even if short names were used rather than numbers or URLs.
It makes a lot of sense to integrate a list of the wcagCriteria met by a
resource into an automated framework that matches those criteria to user
needs expressed in more human-readable ways. And we hope to do something
like that. It would in part be a crosswalk from WCAG to AfA, I think, and
as I described before it would also need to include device, OS, bandwidth,
assistive technology, etc..