WebSchemas/Accessibility/Issues Tracker

From W3C Wiki
Jump to: navigation, search

accessMode and accessibilityMode subtype, proposal 1

Status: open

Dan Scott and Gerardo, on 9/8, suggested the following

I really like your idea for idea for an AccessibilityMode subtype. I tested your code in Google rich snippets tool:

http://www.google.com/webmasters/tools/richsnippets?q=uploaded:8004e5e7c0b2bada99617ef9b8cc4798

And I noticed that in case of Google Custom Search, it will also simplify searching, because the properties are attached to the subtype in your query string. So instead of having to know whether to use the search operator more:p:movie-mediaFeature:captions or more:p:videoobject-mediaFeature:captions you aways do more:p:accessibilitymode-mediafeature:captions.

I think also encasing mediaFeature under this subtype may reduce the desire for it to be renamed and it means that in the future it could be applied to broader non-accessibility related applications.


The solution to knowing which of the accessModes listed for a given resource are required for understanding the resource and which are not has traditionally (in Access for All usage) been that the matching system analyzes several pieces of metadata together to draw a conclusion. Here's the example of a video with captions and audio description, which Charles McN correctly marks up as:

  <div itemscope="" itemtype="http://schema.org/Movie">
    <meta itemprop="accessMode" content="visual"/>
    <meta itemprop="accessMode" content="auditory"/>
    <meta itemprop="accessibilityFeature" content="audioDescription"/>
    <meta itemprop="accessibilityFeature" content="captions"/>
  </div>

We have resources like this in Teachers' Domain. And the solution there to deciding which resources are well-suited a particular user's requirements is to analyze the whole of the metadata in comparison to the user's preferences. If a user cannot see, then if a resource contains "visual" media we look to see if there is a mediaFeature that can substitute for visual. "audioDescription" is an auditory substitute for visual material, so this resource taken as a whole meets this user's needs.

Perhaps, instead of having repeated accessMode and mediaFeature properties repeating directly under http://schema.org/Movie, which (if I understand correctly) makes it hard to correlate accessMode=visual with mediaFeature=audioDescription, these properties should be subsumed under a new Type.

For example, let's call this new type AccessibilityMode and propose that the associated property name be accessDescription, just as a placeholder:

  <div itemscope itemtype="http://schema.org/Movie">
    <div itemprop="accessDescription" itemscope itemtype="http://schema.org/AccessibilityMode">
      Accessible to sighted users
      <meta itemprop="accessMode" content="visual"/>
      <meta itemprop="accessibilityFeature" content="audioDescription"/>
      File:Example.jpg
    </div>
    <div itemprop="accessDescription" itemscope itemtype="http://schema.org/AccessibilityMode">
      Accessible to hearing users
      <meta itemprop="accessMode" content="auditory"/>
      <meta itemprop="accessibilityFeature" content="captions"/>
    </div>
  </div>

This would enable you to keep the mode & feature meaningfully connected, which is I think what you're looking for. And now that we're distinguishing the accessibility mode as a separate Type, all of the standard Thing properties are available to us without being associated with the Movie itself, so you could go also use the "description" property to note any particular restrictions, etc, for each access mode.

accessMode and availableAccessMode, proposal 2

Status: open

  • accessMode for the required set of modes is still very important
  • mediaFeatures, especially the content transformations, are essential both as adaptation and enhancements
  • Search engines seem to be concerned with having the complex rules of accessmodes, modified by mediafeatures, turned into the accessmodes that they believe can be used in queries

The question would appear to be: Does a search engine need to have this accessmode/mediafeature resolved into usable access modes before it can do a query? If the answer is yes (and Charles seems to lean this way) should this be resolved:

  1. By the metadata creator
  2. By an algorithm,. based on accessMode and mediaFeature, when the content is ingested at the search engine
  3. At search execution.

The third option, and the multiple steps would appear to DEFINITELY be off the table, based on Charles McN's comments.


The proposal below is a way to have the accessmodes and mediaFeatures that started the process be built into the resulting availableAccessMode. Let's look at a few examples, using the video example that Madeleine has offered in the video.

A video, with closed captions

Visual, Auditory MediaFeature: captions

Search Engine Access:

  • accessMode: Visual, Auditory (VA)
  • availableAccessMode: Visual, Textual (VX)

A silent video (no audio)

Visual

Search Engine Access:

  • accessMode: Visual

A video with open captions

Visual, Auditory MediaFeature:captions

Search Engine Access:

  • accessMode: Visual, Auditory
  • availableAccessMode: Visual

A video with sign language

Visual, Auditory MediaFeature:signLanguage

Search Engine Access:

  • accessMode: Visual, Auditory
  • availableAccessMode: Visual

A video with audioDescriptions

Visual, Auditory MediaFeature:audioDescription

Search Engine Access:

  • accessMode: Visual, Auditory
  • availableAccessMode: Auditory


And, to take this to an extreme A video had all of the above features (closed captions, sign language, audio descriptions)

Visual, Auditory MediaFeature:captions, signLanguage,audioDescriptions

Transcript is textual if it contains both the transcript AND audiodescription

Search Engine Access:

  • accessMode: Visual, Auditory (VA) - regular video
  • availableAccessMode: Visual (V) - open caption
  • availableAccessMode: Textual (X) - transcript if described both audio and video
  • availableAccessMode: Visual, Textual (VX) - closed caption
  • availableAccessMode: Auditory (A) - if described both video in with the existing audio.

The original accessMode and the availableAccessModes would be what the search engine would access.

The mediafeatures, as Madeleine showed in the video of Teacher's Domain, are useful attributes to have appear in the search results for easier judgement by the end user.

If a person who wanted to find resources for a deaf student (or where the computers had no speakers), you'd say

  1. either that you do NOT want Auditory or
  2. that you do want a resource that is fully usable with the access modes available to the user in their preferences (Visual, Textual, Tactile)

Note that I changed the encoding of the available access modes to be single letters, concatenated into strings in the order we have been presenting them (although I might switch to alphabetic order). This single letter scheme gets around schema.org's way of flattening anything that has multiple values. My opinion is that the accessmode is useful for the author, and that available access mode is what a search engine ultimately wants, as it expresses the full range of available access modes in a simple expression. Users can then make decisions based on the mediaFeatures presented. This solves a problem that was once believed to be a major impediment to hierarchical metadata that existed early in with AfA, Whether this terse form, which would work with microdata, or the next wins is not as much the issue as having a way to support the concet of an adapted accessMode.

accessMode and accessibilityFeature use cases

The bulk of the use cases, as suggested by Gerardo, Jutta, past AfA work or developed in the accessibility metadata effort, boil down to three types:

  1. I am a person who is looking for this media type with this feature. This could be a deaf person looking for captions, a dyslexic person looking for a daisy text book (not audio) or a teacher looking for an image with a tactile graphic
  2. As this person becomes more advanced in searches, they will start to say "I am looking for content on this topic that only uses these senses." For example, it could be a person in a car, who only wants content that can be conveyed auditory
  3. A teacher who is looking for content for a range of students, some with a disability, some not, and would like to give the profile of the disabilities and then make judgements on the applicability of the content. In this case, getting the accessible/ inaccessible flag (as Teacher's domain did do) would be very complex in the search result. with the "available access mode." it would just be a match to see if all of the available access modes of the content (in other words, a deaf user's possible access modes would be VT, so they would match open caption, transcript, and closed captioned).

Is there a need for both isAdaptationOf and hasAdaptation?

Status: open, to be taken up by Bibex group


We should be looking at our needs in light of what's going on in those two areas. Simply stated:


There are two use cases:

  1. Content producer commissions or produces in-house adaptation for a resource - use hasAdaptation
  2. Organisation external to the resource producer produces adaptation for a resource. The resource producer is not informed, gives no permission, does not even know about it. Would use isAdaptationOf.

It is arguable that the adaptation producer might embed the original resource in some tagging structure (html) that uses hasAdaptation instead but just a little of the meaning is lost in doing that. Originally we designed this without thoughts that this Metadata might eventually become universally accepted (as seems likely in your work - yippee!) and it had to deal with the notion that metadata might have to be discovered from the content and that it wasn't always possible to associate Metadata with a resource in a robust way (e.g. DRM, content without Metadata, external metadata repositories are a weak link etc.) so this was provided to support that scenario. If *everything* that might be referenced can have associated Metadata (and I'm pretty sure we are saying that here because as I understand it we're only talking html 5 bindings) then I think it wouldn't be a problem to only have hasAdaptation. But hang on a moment - think Internet of Things - are we completely sure that we are going to *always* be able to associate Metatadata with every "original" resource we might want to have an adaptation for. I'm not completely sure - hence I think there is a case for both right now even if one of the two becomes the recommended practice.

The hope would especially be that this second category, isAdaptationOf, could be integrated into a mainstream search. In other words, independent adaptations, such as a Bookshare adapted version of book in Daisy or BRF could be made known in search when searching for a book. For example, the Bookshare version of CK-12 Geometry could show as an accessible option when searching for "CK-12 Geometry" which would bring up the content that this is adapted from.

Should isAdaptationOf and hasAdaptation property names should declare that they are for accessibility?

Status: open, to be taken up with Bibex group

The specification has been edited with this in the explanation. However, we may want to consider adding "access" into the name.

The concerns from the list follow. I am also concerned about the use of 'adaptation.'

As Karen pointed out, in the "academic and bibliographic world that term refers to changes in the *content* not the physical or digital format." This leads me to think of something ugly such as hasAdaptionForAccess & isAdaptionForAccessOf or 'hasAccessAdapation" & "isAccessAdaptationOf." Otherwise I foresee confusion on the part of data producers or consumers as to assumptions as to the use of these properties.

As for loading all meaning of terms into increasingly long names (adding "for access") as a suffix, it's not clear whether this adds or removes clarity. These issues are better handled in the description than overloading the name. But Karen and you are right that the issue needs to addressed, possibl with more than just documentation.

Value Issues in version 1.0

Status: open, with the changes being edited into the 1.0 specification

The following name change is proposed for clarity:

  • enhancedAudio -> highContrastAudio

The following values are to be deleted from accessibilityControl as they do not define input methods:

  • fullAudioControl
  • fullVideoControl
  • timing

The values will instead be added as accessibility features:

  • audioControl
  • videoControl
  • timingControl

The following values will be added to accessibilityControl:

  • fullVoiceControl
  • fullSwitchControl

The following extensions of structuralNavigation will become top-level values:

  • tableOfContents
  • readingOrder
  • printPageNumbers
  • index
  • taggedPDF
  • annotations

Three proposals are suggested for dealing with the overlap of functionality and CSS in displayTransformability, resizeText and highContrast:

Proposal One

Remove the dependence of displayTransformability on CSS and make resizeText and highContrast subclassifications:

  • displayTransformability – the appearance can be controlled regardless of how that is done
  • displayTransformability/css - display is generally controllable through css
  • displayTransformability/text – more specifically that text is known to be controllable (css or not)
  • displayTransformability/contrast – same but for contrast levels

Other specific subclassifications, such as the specific css properties that can be manipulated would also be possible.

Proposal Two

Change the meaning of the properties (and rename) so that CSS is only a factor in one:

  • highContrastDisplay - the content meets SC 1.4.3 thresholds for contrast (without user manipulation)
  • textControl - the user has control over font, line heights and word spacing (without adding custom style sheets)
  • cssTransformability - the user can control the default appearance through custom style sheets

Proposal Three

Keep highContrastDisplay as a property to indicate the initial state, but adopt displayTransformability as defined in the first proposal.

Resolved Issues

I have moved much of the historical information out to an resolved issues page. A short view of the issues are

  1. What is the overall goal of this proposal?
    1. status: closed with adoption of 1.0
  2. accessibilityHazard - is the sense correct
    1. status: closed with the addition of the "no" property values in 1.0
  3. What is the goal of accessibilityFeature?
    1. status: closed. The different classes of accessibilityFeature were detailed in the 1.0 work
  4. Adopt standard access prefix for all the names
    1. status: closed. All of the properties in 1.0 begin with the string "accessibility"
  5. Evolution of the vocabulary of property values or Change type "text" for schema.org values to enumerated values
    1. status: closed. The controlled vocabularies will be controlled on the public vocabs wiki on w3.org
  6. softwareApplication properties: accessAPI and controlFlexibility, ok or not?
    1. status: closed. These were renamed in 1.0 and made applicable at the highest level
  7. Consider whether ATCompatible is even necessary, or should be a new name.
    1. status: closed. This was deemed too confusing to be generally adopted, and is no longer under consideration
  8. What is the proper level of detail for ATCompatible (continuation of previous)
    1. status: closed. This was deemed too confusing to be generally adopted, and is no longer under consideration

Old Content

I have moved much of the historical information out to an old and historically interesting, but not directly relevant page. This helps show the evolution of thought as we worked through the accessibiltyFeature structure.