Re: [a11y-metadata-project] The next Accessibility Metadata call will be at 9:00 AM PDT on 10/29 to try to wrap on mediaFeature

I have one comment below on mediaAugmentationFeature.  Simply stated, this is the one property that has an impact on the accessMode.  So, as I go to write the part on how to deal with accessModes that are available rather than just sourced, it should be clear that the "AugmentationFeatures" are the ones that have accessMode implications.

This may all come back together again into one attribute called mediaFeature with three different semantic buckets of meaning.  But, just as we moved from eight buckets to three this week, I'd like to save the next consolidation for the next phase.

See other comments inline with [CRM]

On Oct 28, 2013, at 7:41 PM, Madeleine Rothberg <madeleine_rothberg@wgbh.org<mailto:madeleine_rothberg@wgbh.org>> wrote:

My apologies to all. I won't be able to meet this week. Here are some of my opinions in response to Chuck's questions.
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)

[MR] I like transformable — it is the most explanatory. But is it too much jargon? Is there something even simpler we haven't thought of? How about flexible?
[CRM] The best way to be jargon-free may just be the /enabled, or even /allowed


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

[MR] I think that, like our decision on hazard, we should not make a term that today means "all three of those" but tomorrow could be interpreted as "all five of those" if the rest of the vocab is expanded. Either we have only displayTransformability, which means "totally flexible," or we have a list of kinds of flexibility if we think some resources will be transformable in one way but not others. I think that the enumeration came from the intent to capture fixed-but-larger resources. So I guess I'd suggest we'd keep that use, but not add the /transformable extension, if we decide to have the omnibus displayTransformability value.
[CRM]That's a great argument for dropping displayTransformability. I had some trepidation about putting it in as a shorthand, but you described the pitfalls of the "all of those" better than I had thought it out.  Let's drop displayTransformability.


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.

[MR] I am uncomfortable with the push to split the features up into little boxes with their own names. Do we expect that to add clarity for web developers who are new to accessibility? I could be wrong, of course. If we go ahead in this direction, the names should be as simple as they can be, since they are essentially serving as documentation of the meaning of the values inside. Another alternative is the single long list but good definitions for each term.

[CRM] See comments at the top.  These are artifacts of discussion, and may not be the way that they end up (although the buckets may be in the presentation of the property values and the documentation.  One of the challenges is that schema.org<http://schema.org> presents the attributes in a relatively flat sense, without significant context, and it's not clear to me that context specified in external documents will have an impact.  I'd love to hear more from the schema.org<http://schema.org> folks on this.

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.

[MR] That might have been me. I think I mentioned that some people with learning disabilities can benefit from seeing pictures related to the text they are reading, to give context and support the meaning of the text. I wouldn't call captions an alternativeImage, though, if that is what that sentence is supposed to be saying. They can be visual (if not true text) which makes them textOnImage in current vocabulary. But saying they are an alternativeImage feels wrong to me.


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

[MR] Is there a difference between a chart and a diagram? There are lots of kinds of both, but I think one term covers them all. "There is data here. You'll need it in another form if you can't see or can't read text in images." Are icons important to call out as separate from other kinds of images? (Someone may have presented a use case that I'm forgetting.)

Again, I'm sorry to miss tomorrow's call. I hope it is productive and I look forward to seeing the notes.

-Madeleine

--
Madeleine Rothberg
Project Director
Carl and Ruth Shapiro Family National Center for Accessible Media at WGBH
http://ncam.wgbh.org
madeleine_rothberg@wgbh.org<mailto:madeleine_rothberg@wgbh.org>

--
You received this message because you are subscribed to the Google Groups "Accessibility Metadata Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to a11y-metadata-project+unsubscribe@googlegroups.com<mailto:a11y-metadata-project+unsubscribe@googlegroups.com>.
To post to this group, send email to a11y-metadata-project@googlegroups.com<mailto:a11y-metadata-project@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.