Minutes 10-22-2013

Skip to end of metadata
Go to start of metadata

October 22, 2013 9:00 AM PDT (regular call time)


Attendance: Put a "*" next to you name when you join

Andy Heath
Madeleine Rothberg 
Liddy Nevile
Charles Myers
Anastasia Cheetham
Jutta Treviranus

Major items concluded with mediaFeature and its properties

We had significant discussions around textualTransformFeature and visualTransformFeature. It's worth noting that the primary concepts in WCAG 1.4 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 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, 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.
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

Agreement on the basic use cases, for the record

While this was not discussed in this meeting (it was on 10/7&8), I have left this here so that we can continue the focus on this. We discussed three use cases as the basic types (the sensory modes change the story, but the story is the same)
There are three use cases below

  • a person looking for a specific media type (video) with a mediaFeature (caption) - media type+mediaFeature does the job well
  • a person driving in a car who can only work with audio content or content that can be expressed in audio - needs accessMode to easily determine useful content
  • a teacher who is leading a class, where some of the students have disabilities. They would like to find resources for the class, finding, if possible, the best resources that can be used by the most students - another case for accessMode
  • are there more?
    • When a book is made available, it may be available with different accessModes and mediaFeatures (the current bookshare is a very good example... a book can be available in braille (brf), Daisy with images, Daisy w/o images and Daisy Audio, all as adaptations of the source book
    • When a book is available on O'Reilly or Amazon, it may be available in a few formats from the offering page (paper, epub, mobi, pdf), hardbound, paperback, audioCD or AudioService (Audible). Sometimes these are available for access directly from the page (O'Reilly). Other cases (Amazon), has links over to that page.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.