WebSchemas/Accessibility/Issues Tracker/ResolvedIssues

From W3C Wiki

What is the overall goal of this proposal?

Status: closed. This was resolved in the 1.0 on 12/4/2013

It is a draft proposal that has been in development since January 2013, and made available for comment on April 15, 2013. There have been a number of questions on the scope of this proposal, as the term accessibility is quite open. Here's a quick view.

  • It focuses on creative work (content:books, video, audio, images, web pages and software applications) to describe the accessibility attributes
  • It does not not focus on physical places and their accessibility characteristics, nor does it do this for events.
  • While it will aid finding content appropriate for a specific users preferences, we do not have the matching algorithms of CC/PP of Access for All's PNP in mind. Additional metadata can be added to the content to take advantage of this. It;'s for this reason that we have tried to stay as close to ISO 24751 and existing best practice as possible, coordinating closely with both ISO 24571/AfA and Dublin Core Metadata

The goal is easily described as making accessible content discoverable. While WCAG, PDF/UA and other efforts strive to create all content as accessible content, there is still immense amounts of content that was not designed with accessibility in mind, whether by cost, ignorance or legacy. Finding accessible content is often akin to finding a needle in a haystack of inaccessible material.

To accomplish this, it is important to focus on making the metadata easily specified, with a minimal number of properties. This is both so that it's easy for web content creators to characterize their content and for users to have a minimal number of terms for search. There is much more detail that could be represented in these properties, but they create such a large number of properties and values to render them less than useful for people looking for their type of accessible content.

Charles suggested a better standard, which is to make simple things simple and hard things possible. This may be an extension of our original goal.

accessHazard - Ok as is, or should it be negated in sense or allow a "none"?

Status: closed on 10/7/2013 with the addition of three negative assertions as well as the existing positive assertions.

The decision was to create three negative assertions to match the positive assertion. All three of the negative properties should be set if there are not any of the hazards known to date. If not properties are set, the state of accessHazards is unknown, rather than no hazard.

Also, here are notes from the 10/7 meeting

  • Currently, accessHazard defines positively. The resolution is that we have negative assertions that match the positive assertions. and not a "none"
  • The reasoning is that the maths works out better: 10% of content marked correctly as having hazard if it does means there is a 90% chance of hitting a hazard.
  • The definition in our spec should refer to seizures, nausea or other physical (Myers should look at AfA and make sure that I capture the meaning of AfA... Matt and I may have been overly aggressive in editing). I checked the wording after the call and believe that it is fine.

Below is the original dialog.

Note that, since the dialog started, this has been constrained to just the hazards defined in WCAG 2.3. The proposal has been updated.

There are two opinions running on this at the moment. We need to decide.

  1. accessHazard is fine as stands. Only content that has an accessHazard should have these properties set
  2. the values should be set in the negative. I think we want to replace accessHazard with a negatively expressed version ("doesNotHaveAccessHazard") but in the meantime I think adopting the existing accessHazard would be a good idea.

Madeleine: I believe we need both accessHazard=flashing and accessHazard=noFlashing, etc.. This is because there are three cases we'd like to distinguish:

  1. checked and it's fine
  2. checked and it is NOT fine
  3. didn't check

"Didn't check" can be signified by no metadata -- this will be most of the content on the Web. In cases where someone has checked, let's record both positive and negative states.

There was a larger debate about other poorly designed inaccessible content. This property was intended just for items that can induce seizures.

I've also reproduced a reply I wrote in email on style and a drive to adoption.

I'd just like to point out that we have two competing aspects here... Precision and adoption. And then an understanding of who the audience is for these tags.

Precision: Yes, specifying the exact three hazards that we know and specifying them is the most correct way to specifiy the information

Adoption: If we tell every video producer (e.g., Khan Academy) that they should be adding

<meta accesshazard="noflashing">
<meta accesshazard="nomotionsimulation">
<meta accesshazard="nosound">

I'd settle for making it easy for them, if they know there are no hazards (which, I am sure is true for 99.99+% of their content). I'd have trouble to convince them to do

<meta accesshazard="none">

But that's more likely, at least.

Audience: The people who will be adding these tags are ones who are accessibility advocates. If a new accessibility hazard that prompts seizures is discovered and they have done the work to tag their content already, they would be the most likely group to do this.

Our greatest challenge with this specification is not going to be one of getting accessibility advocates to do the right things. It's going to be getting the regular web masters and the like to add accessibility tagging at all. And we can help to achieve this by making this as simple as possible, while not compromising information content.

This challenge on precision vs. adoption runs through the specification. If we ask people to do too much, they'll throw up their hands and not do anything at all, or do it wrong. We've tried to error towards adoptable.

What is the goal of mediaFeature? (conforming or informational) Do we have this right?

status: closed in 1.0 on 12/4/2013 with the updated description of the different types of accessibilityFeature

Charles raised the question of whether these attributes are a declaration of conformance (as in alternativeText means that "all of the photographs and other media have alternate text") or just whether the author of the content (or adapted version of the content) used alternate text on the significant parts of the content to the best of their abilities. The intent of these are the latter. Since this metadata is being added by people who care about accessibility, we have to trust that they will apply their best efforts before they'd add the attribute.

A framework to understand the accessModes and mediaFeatures has been written on the main wiki page (now in OldContent) , and should serve to answer most of these issues. See especially the second numbered list in this, which outlines the two main classes of mediaFeatures:

  1. Display or Transformative or just Transform - restyling, adjusting layout, while staying within the same access mode. This is row 3 of the table. These adaptations are enhancements or alterations in presentation that do not require intellectual interpretation or alteration of the content within the same accessMode.
  2. Augmentation or Content - adding captions, descriptions, alt-text to augment an accessMode to another accessMode. This is the bulk of the table, from row 4 column 4, down and to the right. This class of mediaFeature does require a human or other intelligence to interpret the intellectual content and make it available in another accessMode.

Charles McN, on the mailing list, wrote the following (in italic, with the response upright).

It isn't clear what the requirements and use cases are for mediaFeature.

Are these just cataloguing information, similar to noting that a physical book has 5 pages of color photographs, or a guarantee that e.g., each image has alternative text, or a longer description is provided as necessary?

We thought that implementing AfA or ISO 24751 verbatim for the purposes of web search and for use by web masters would be too complicated: it needed to be a small set of properties that a user could deal with. We decided to combine various ideas into mediaFeature. mediaFeature simply states that the author/publisher or someone who modified that book, tried to take advantage the stated accessibility features. For example we make no promise that every image was described appropriately, since it is hard to define that by a single person and actually different consumers of the information may have different opinions about the quality and coverage of the image descriptions.

It seems that they are the former - interesting information that might lead to expectations of the resource described. They don't seem well-enough specified to know if I can rely on them. And the list seems somewhat arbitrary.

It isn't clear, for example, how to classify a resource that assumes the ability to touch several points of a screen at once, which is now a common feature on devices but poses an obvious potential problem to some users such as those who don't have very many fingers.

In this use case, the resource that needs to be described is an application, not the content. If the accessibility API of this application supports multi-touch with the user’s AT, then the proposed ATCompatible and accessAPI properties should be relevant. Furthermore, we also have a property called controlFlexibility, which also should provide information about whether the application can be fully controlled either via audio, mouse, keyboard, touch or video/gestures.

There are specific properties for interactive applications (softwareApplication, which includes web applications). These are ATCompatible, controlFlexibility, and accessAPI. The mediaFeatures are for the full breadth of CreativeWork, but just focus on the content, not the interaction.

Finally, Charles McN proposed that we use a proposed display/transformative property of "audioHighContrast" as a though experiment. My take is that such a property, if existent (would love a reference) would be in the fifth column, third row, as +audioHighContrast. It's a transform that would have been applied to the source, much like largePrint is a transform on visual when it is an image.

This has been handled with enhancedAudio.

A significant amount of content here, used in the development, has been placed in an old content area. WebSchemas/Accessibility/Issues Tracker/OldContent#Access_Mode_and_Media_Feature_Framework:_a_tabular_view

Adopt standard access prefix for all the names

Status: closed, with decisions of November 5, 2013 to rename properties (they changed a bit more in the final 1.0, but the discussion is here)

The property names are now

  • accessMode
  • accessFeature
  • ATCompatible -accessTechnologyCompatible (or just accessTechnology?) - covered elsewhere
  • accessHazard
  • accessAPI
  • accessControl

Editor note… There was a major move early on in the specification to NOT have the names be solely tied to accessibility, but to have them express general concepts when possible. That's why "controlFlexibility" did not have accessibility in the name, nor did mediaFeature, as they were more broadly applicable. It appears that the desire now is to clearly label this as accessibility related and in the same alphabetic range so that they are easiliy identified, with continuity, in the large spec of schema.org.

I believe that implementers of schema.org would benefit from having the accessibility properties colocated as much as possible in the schema.org documentation, and therefore would recommend that the new primarily accessibility-oriented properties be renamed with "access" as a standard prefix; for example:

  • accessMode
  • mediaFeature -accessMediaFeature (or just accessFeature?)
  • ATCompatible -accessTechnologyCompatible (or just accessTechnology?) - covered elsewhere
  • accessHazard
  • accessAPI
  • controlFlexibility -accessControlFlexibility (or just accessControl?)

Evolution of the vocabulary of property values or Change type "text" for schema.org values to enumerated values

Status: closed. The decision was to use the schema,.org wiki page to maintain the active list of the property values.

Who looks after the terms, and how do they get extended?

Proposal: Use GoodRelations or 24751 registry, beyond scope of schema.org proposal

This is probably the problem with any Schema.org proposal. By basing this proposal on existing standards, such as AfA and ISO 24751, it will be easier to evolve these terms as more people and organizations (e.g., IMS, GPII, IDPF) will be invested in keeping these terms synchronized with other standards and technologies. We believe that there are some efforts with 24751 to have a registry to assist in this process.

Some things are pretty basic and could be reliably laid down - the ability to see or hear is something that we more or less understand. But others, such as interacting with new types of device, will probably change. Pointer and especially touch interfaces have changed a lot in this century, voice interfaces are starting to do so, and gestural things like Wii and Kinect are beginning to appear more often too.

That's enough comment for now. Hopefully I've clarified the main threads that I think need action (some more urgently than others).

Sorry for the long answer, but I wanted to make sure that you understood why we deviated from AfA v3 and were hoping that that effort would move to the new terminology with us. You'll find a number of these, such as the "colorDependent" access mode, which was one of Dan's earlier comments, which was much more clear than just "color." I hope this helps. Thanks for asking for the colorDependent makes sense. We have been discussing folding back schema.org, IndieUI, and APIP into AfA V3.

clarification. They key is that we subsetted the AfA work to the minimum set (looking for adoption) and improved names, with feedback to AfA, for many values.

That is an excellent strategy as if we go to far with the vocabulary we will lose adopters. In AfA V3 we worked developed a Core and Extended Vocabulary for this reason. I don't know if it was a small enough subset for what you are doing with schema.org but we certainly would be willing to adapt the core set.


In general, those properties with an expected type of "Text" that have a list of expected values (such as accessMode, mediaFeature, accessHazard, accessAPI, and controlFlexibility) should be redefined to have new enumerations as their expected type. And, ideally, the valid values for those new enumerations would be maintained externally (perhaps by the IMS Global Learning Consortium itself). I'm not the first to mention a concern over how these values will be maintained going forward, but I firmly believe that delegating this responsibility to an external entity with expertise in the area is the best plan for long-term success.

For an existing example in schema.org, the http://schema.org/Offer type has the http://schema.org/businessFunction property, which in turn has an expected value of http://schema.org/BusinessFunction - an enumeration that points to the Good Relations vocabulary for its valid set of values.

softwareApplication properties: accessAPI and controlFlexibility, ok or not?

Status: Closed. The names were changed in 1.0, and elevated back to being applicable for all of CreativeWork

There are a few questions here:

  • Should the names be changed to be generic operating systems (resolved to no, esp. with ISO/IEC JTC1 SC35 13066
  • Is controlFlexibility adequately defined, or will this be changing in the future? A: The control parameters were limited in AfA, so we extended them in advance of need. These may change over time.
  • ATCompatible/Interoperable should be considered at the same time as this.

The values of accessAPI and controlFlexibility are needlessly special-purpose, I think. It would be better if these values were named/defined in a way that is reusable across Schema.org, e.g. iOS (instead of iOSAccessibility), Java (instead of JavaAccessibility), etc.

CRM: These names were more difficult to choose than the group would have expected. I'd venture to say that there was no clear best answer. Some of them, like MSAA are acronyms for Microsoft Active Accessibility. I don't think we could shorten this to Microsoft... it's a specific branded API. Other platforms had their specific APIs to support accessibility. I don't think you can more from the name of the API to the operating system platform without a serious loss of information value.

That being said, the names are verbose and somewhat inconsistent. But it's the SW platform manufacturers who created this inconsistency... I don't think it's our place in metadata vocabularies to clean up their branding mess. In other words, we were

As a final note, we did limit the scope of these properties (accessAPI and controlFlexibility) and values to software application, not the full creative work. When someone describes the capability of their application, whether game, mobile app or web app, I'd think that they'd have a pretty good idea of the accessibility properties, especially as they would have (in the US at least) filled out a VPAT and thought this through).

On the topic of API names - the API's themselves are specified as standards in ISO/IEC JTC1 SC35 13066 series (each is a technical report). Each has a name in there but in English text with spaces and so on. We abbreviated the names in the vocabulary in AfA 3.0 - there is an argument there should be a standard vocabulary somewhere - but what also matters is the way that is de-referenced - if the standard that defines that API is referenced the name isn't too important imho.

I would question the value of controlFlexibility as we move into a world of tablets and gestures, in 2 or more dimensions, which is why we gave it such a limited vocabulary. I didn't check what it is in this work but we made it just {fullKeyboardControl | fullMouseControl } so it could be used for desktops, with the view that we needed something more for touch devices - however that something more needs work in device operating systems and API's (which we are doing in IndieUI but has some way to go). There is also work relevant to this that is ongoing in SC35. My personal (and it is *only* personal - not representing any organisation here) is that its too early to do much with vocabularies that determine how a resource can be controlled because its evolving with devices in the market place very fast.

3. iOS does NOT indicate an accessible solution on that platform. The same goes for Java. The concern with using general terms suitable for use anywhere in schema.org is that metadata authors think they are filling out what OS their app is used for, while we are asking specifically, "Did you follow the accessibility API for that platform?" Elsewhere Andy said we might not need this when there is only one API per OS, but there are cases where there is more than one, notably Windows, and there is always the possibility for more splintering. As Charles Myers commented, these APIs are named specifications or documents from OS developers, and we are referencing those specific documents.

Simply because something runs on iOS or Windows does not mean it is accessible and it does not mean that it is using the accessibility API for that platform. It may use Java or it may indeed use multiple technologies to form the app. So, If this were to be specified as a second property we would need to accommodate an enumerated list of values that means it is accessible on that platform. Also, accessibility API can be version specific. For example UI Automation was extended for Windows 8. We would need to provide for version identification.

Consider whether ATCompatible is even necessary, or should be a new name

Status: closed. This was not considered for 1.0, and is not under consideration for future effort. The property succeed in being both too limited and too broad, with requests for specific property values to be considered. With adoption unlikely due to this ambiguity, it was decided that the accessibilityFeatures were sufficient information.


The discussion is whether we need to have ATCompatible at all, or whether it can be handled by adding one or more properties to mediaFeature.

Note that this discussion brought up the fact that this property is more applicable to just softwareApplication and not content, so it has been moved down to the softwareApplication area. This simplifies the

ATCompatible came from ATInteroperable of AfA. As we reviewed the accessMode/MediaFeature matrix, it seemed that much of what we proposed for this attribute was being expressed in concrete mediaFeatures. I used the simple summary of WCAG 2.0 at Webaim for reference.

  • 1.1.1 Text Alternatives: Provide text alternatives for any non-text content (this is covered well in MediaFeature, with many alternatives)
  • 1.3.1 Semantic markup, Table markup and text labels (NOT COVERED IN mediaFeature)
  • 1.3.2 Meaningful sequence for reading and navigation order (structureNavigation covers much of this)
  • 2.4.4 Link purpose in context (Not covered in mediaFeature)
  • 3.1.1 Use of language tagging for page (not covered in mediaFeature)
  • 3.1.2 Use of language tagging for parts (not covered in mediaFeature)
  • 3.3.2 Labels or instructions for interactive (relevant only for softwareApplication)
  • 4.1.1 valid html/xhtml (just basic goodness)
  • 4.1.2 Markup facilitates accessibility, defining name role, value

Our mediaFeature already covers two of the more significant WCAG sections: we have overlap already. On reviewing DAP, they propose a property of whether the content is set up for TTS (both a licensing issue and a text structure). It may be that 1.3.1, 3.1.1, 3.1.2, and 4.1.1, 4.1.2 can be summarized as whether the text is set up for TTS or readability. The proposal is that we eliminate ATCompatible and we create a mediaFeature to state whether the text is set up for a reading/TTS system.

As we think about accessibility tagging, it's worthwhile to look at the STEPP DAP project. A review of their properties, where they took their own look at accessibility labelling independent of AfA efforts, brought up a good set of data, such as the TTS-enablement. We did a crosswalk of their properties, which is available on the accessibility metadata wiki.

The old notes for the discussion follow

  • AccessTechnologyCompatible
  • AccessTechnologyInteroperable
  • AssistiveTechnologyCompatible
  • AssistiveTechnologyInteroperable

Whether it continues to be defined as a Boolean or it evolves into an enumeration, "ATCompatible" is an extremely opaque property name. Despite the additional length, I think it would be helpful to spell it out as assistiveTechnologyCompatible (or accessTechnologyCompatible, or accessTechnology if it evolves into an enumeration).

Actually, it was supposed to be ATInteroperable (from Access For All). It means that the web content was designed to be interoperable with an assistive technology and the original spec. states which WCAG checkpoints are applicable. This is extremely important. By interoperable it means that the content is capable of enabling a browser to support the native platform accessibility APIs. For HTML5 this would mean through the use of content with strong native semantics and/or ARIA support. ATInteroperable does not mean fully WCAG compliant but it adheres to a subset of the requirements. For example, A Screen Reader, Screen Magnifier, or accessibility test tool user would ask for ATInteroperable content. This type of vocabulary is also such that it does not declare the users medical disability.

ATCompatible is the wrong choice as it could mean that your keyboard keys don't conflict by looking at the name.

I am a member of the AfA V3 working group. The problem with ATCompatible is that (in my mind) it extends the definition to things like not having keyboard conflicts which will be rather hard to specify as each AT has their own front end and there is nothing to enforce that.

I was one of the authors of IMS AfA 3.0 along with Rich, Madeleine and Anastasia and an editor of 24751 and why we did this always slightly baffled me also. What API is actually required will be known at delivery time because the browser will know what platform its running on (assuming one accessibility API per platform/browser) - and the API required is also expressed as a preference (PNP) - but still not specifying the exact conformance required imposes something on the negotiation/search. One argument is that it could be appropriate to expect content to conform to *all* device accessibility API's but this does seem unrealistic, particularly with the coming Internet of Things (how many device API's will there be, who knows).

What is the proper level of detail for ATCompatible (continuation of previous)

Status: closed. See above

being a boolean seems a bit naive. I can think of lots of resources that work with specific assistive technologies, but fail with others (my instant example is http://cookiecrook.com/longdesc/iframe/ which works great on VoiceOver but as far as I can tell does nothing to work effectively with the built-in MacOS magnifier - two assistive technologies I have readily available…).

In the case of content, we once again, we tried to simplify the work for web masters and searchers. Since we can always expand the vocabulary, we decided to err on simplicity, and to just have the focus on whether accessible technology was considered; enumerating WCAG sections would be overly daunting in a search. In the case of applications, we did provide greater granularity with the accessAPI property, which would differentiate what accessibility API, such as VoiceOver, the application is compatible with.

Let me give a bit of background on the choice of the name ATCompatible, as opposed to the ATinteroperable.

There was a great debate in the working group on two property names, apiInteroperable and at atInteroperable. I'll give a short summary Especially in the context of schema.org where the properties would not be in standalone areas for accessibility, but would be intermingled with all the other properties, they had to have the least ambiguity in property names. With that, atInteroperable became ATCompatible, meaning that it is intended to work with accessible technologies. This suggestion was to have been communicated back to AFAv3, as it was just being added in this version (it was not in the ISO version) and was in draft mode. Also apiInteroperable, which was ambiguous outside the accessibility context (which API?) became accessAPI.

The good news is that we're talking about the exact same thing. But the audience for schema.org is much larger than the set of people who might look at AfA: we needed them to be able to stand alone without the accessibility context.

ATCompatible is defined as a Boolean property. It would be more informative if it were defined as a property with an enumeration of values relating to WCAG 2.0 checkpoints or to some other means of qualifying the nature of the compatibility with assistive technologies.

Agree. And I think that is what Rich said the idea is meant to be (although having the value as a boolean loses that).


CRM:Yes, it might be informative to have all of this information detailed for search. But would a person searching for content on the web look checkboxes that looked like (imagine the * as a checkbox)?

  • WCAG 2.0/1.1.1
  • WCAG 2.0/1.3.1
  • WCAG 2.0/1.3.2

... I think not.


A person looking for accessible content would most like to know if the creator asserts that they have made this content so that it is intended to work with screen readers and other accessibility technology. The content of the web page can always give more detail of what is supported or not. Also, if we make the burden of telling all of this information too severe, we're likely to not get anything.

Rich: 2. ATCompatible: The user is not going to recognize a list of checkpoint numbers and recognize what is useful to them. They really need to know that the author believes that the content is compatible.

To underline this point, our goal is some reasonable set of info on a user's search results. The vocab should be as straightforward and user-comprehensible as possible.

I understand why the inverse of the property is required, and I see that we need to distinguish the accessibility solution from, e.g., the platform. As for issue 2, I think it would be best to split ATCompatibile into two properties: one could be a Boolean indicating overarching compatibility, but I think it would be useful to have a second property indicating specifically what form that compatibility takes. Charles is right that a person doing a search will probably not be familiar with the relevant checkpoints, but I can easily imagine apps that could make use of this information to provide a highly targeted set of offerings to a user. (but this starts to get to a higher level of complexity of tagging, where people are likely to not bother to tag this at all... remember that all of these tags are optional)