The next Accessibility Metadata call will be at 9:00 AM PDT on 10/29 to try to wrap on mediaFeature

And we have an action-packed agenda.  Last week was a deep dive into the finely divided and extended mediaFeature.  It took a while more than I expected to write up the minutes, but they are done now.  As they're long, here is the link https://wiki.benetech.org/display/a11ymetadata/Minutes+10-22-2013

Tomorrow's call will be focused on getting the last issues on mediaFeature and accessMode refinements behind us.  Since most of the agenda is a review of last week's minutes and making the decisions in bold, I've copied the agenda below.  Your thoughts on the bold items are your homework.

mediaFeature changes for review

We had significant discussions around textualTransformFeature and visualTransformFeature. It's worth noting that the primary concepts in WCAG 1.4<http://www.w3.org/TR/WCAG20/#visual-audio-contrast> are the three that we settled in on (highContrast, largePrint and resizeText). I have left in bold the followup discussions that need to happen in our next call.

  *   highContrast can have specific color combinations listed (and the spec noted the primary ones of these), but can also be /enabled or /transformable (we considered /css as well)
  *   LargePrint can either have a specific size or /enabled, /transformable or /css (we need to pick ONE of these names)
  *   resizableText, would have one of the three properties above, depending on the name that we pick
  *   displayTransformability, as a property value, says that all three of the above (highContrast,largePrint and resizableText) are enabled by CSS. We need to decide if we want to allow this shorthand at all, or if the attribute values on the three properties are sufficient.

We discussed the two basic types of mediaFeature and concluded that there was a third class needed

  *   mediaTransformFeature are the set of properties that describe the embellishment of the properties of an accessmode, while not converting the content to another access mode. [I'll note that WCAG 2.0 Guideline 1.3<http://www.w3.org/TR/WCAG20/#content-structure-separation> calls this "adaptable, so we may want to consider calling this mediaAdaptableFeature]. We need to decided on the name... Transform or Adaptable
  *   mediaAugmentationFeature. We weren't able to settle on the name for this, but it's the application of intelligence and judgement (currently human) to bring the meaning of one access mode to another. Decide if Augmentation or something else.
  *   mediaStructuralNavigation, while very important, did not fit into the transform/augmentation framework above. We concluded that it should be its own property, especially as it applied across multiple access modes. The values would be the same as what had been previously described (tableOfContents, index, tags, etc.). We need to decide on the name of the property.

We then reviewed the other mediaFeatures.

  *   haptic, which was added to AfA to be thinking a bit towards the future, did not make sense as a tactileTransformFeature. If anything, it's a mediaContentFeature and will be moved there.
  *   visualContentFeature provoked some interesting discussion. This can best be summarized that the contentFeatures described were actually about taking text or audio and presenting them in the image/visual, and that we might be better off if we actually just called this alternativeImage, with the values of
     *   /caption
     *   /signlanguage, which can be followed by the ISO 639-2 language code (reference<http://www.evertype.com/standards/iso639/sign-language.html>, although I am sure that someone could find something more authoritative), such as /sgn-en-us
     *   another concept that Liddy or someone expressed that I did not capture in my notes, but it was along the lines of having access modes in textual expressed in alternative image form.

While I was looking in WCAG 1.4, I found the audio enhancement that Charles McN had been describing.  It is listed in 1.4.7 as Low or No Background Audio<http://www.w3.org/TR/WCAG20/#visual-audio-contrast>.
I propose that we add a auditoryTransformFeature of

  *   enhancedAudio, which can then have one of three extensions
     *   /noBackground
     *   /reducedBackground (the WCAG concept 20 dB)
     *   /switchableBackground (the WCAG concept "turn off")

One item from the editor.  I will have a new revision of the mediaFeature section by the end of the day on Monday which expresses the primary properties (going back to a simpler view) and the extensions listed as footnotes.

Open issues on mediaFeature/ accessmode refinements

  *   We discussed whether the refinements of accessMode should be "OnImage" or "OnVisual," referring to the access mode. While I was ready to just say that it should be OnImage, there was a desire to discuss this again in the next meeting, as we ran out of time. Should /textOnImage really be OnImage or OnVisual?
  *   There was also a desire to add (and which need to be discussed)
     *   /iconOnImage
     *   /diagramOnImage
     *   /chartOnImage