Minutes 10-29-2013

Skip to end of metadata
Go to start of metadata

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

Minutes

Andy Heath
Liddy Nevile
Charles Myers
Anastasia Cheetham

Conclusions

We discussed a number of things during the call, all revolving around coming to a conclusion and consensus on mediaFeature. These were

  • displayTransformability: we agreed to let this stand, with the value of at least CSS. However, most of the user-understandable names are broken out seperately (largePrint, highContract, resizeText). displayTransformability stands alone; specifiying it does not imply any of these three more specific properties.
  • largePrint, highContrast, resizeableText: besides specific pointsizes for large print (e.g., mediaFeature="largePrint/16") and specific color combinations for highContrast, the extension /CSSEnabled can be used to say that the document has been set up for flexibility in those areas through CSS. If other flexibility schemes are found in the future and used, there can be other /XYZEnabled.  But since we don't know what those others are, we decided to be explicit with how this flexibility was enabled now.
  • Andy suggested that the most important thing was to agree on a common data model such that if the Metadata were to include suggested usage relationships between modalities that could be used accessibly in the view of the metadata author then that usage information should be presented separately from the access modalities physically present in the resources. This would enable information both approaches to be used entirely separately without making description of the accessModes present more complex than it need be.
  • We had a long discussion about mediaFeature and the names of the divisions of this attribute. We considered four different choices, with an overall view that the names would be short if the design of the metadata structure was right. The choices were
    1. mediaFeature (within access mode), mediaAugmentation (cross access mode)
    2. mediaFeature (within access mode), accessFeature (cross access mode)
    3. accessFeature as the new name for all three classes, and we describe them in sets
    4. mediaFeature as the old name for all three classes, and we describe them in sets
  • We did not reach a consensus on the choices above and I need to have something to go forward with. I will change the specification to reflect #4, mediaFeature. We did, however, all seem to have some degree of affinity to accessFeature, which may have been its original name before the change to mediaFeature. I'll add this to the agenda for the next meeting, but it's going to be a simple up/down discussion (I'll note that we started as "hasFeature," then moved to "adaptationFeature" and then settled on "mediaFeature"). The good news is that the suggestion of accessFeature IS a new one, but I'd be willing to say that, if it changes at all, this will be the last time we ever change.
  • We concluded that haptic, as an access mode, was actually a refinement of tactile, and was not a mediaFeature. It's being moved up to this new place (although I'll admit that tactile.haptic does not fit the syntax that AfA has used for refinements).
  • We discussed enhancedAudio and decided that it, and the three attributes were good and should be adopted. Note that the basic concepts come from WCAG 2.0 section 1.4
    • /noBackground
    • /reducedBackground (the WCAG concept 20 dB)
    • /switchableBackground (the WCAG concept "turn off")
  • We had a brief discussion on AlternativeImage, but it was not resolved, especially as Madeleine had some further opinions expressed in email, but was not present due to Edupub,  We will take this up in the next call.
  • The next thing to tackle will be AccessMode, where at least Chuck and Anastasia agreed to write up material and have another proposal in the issue tracker.

Note that the issue tracker on the w3c wiki has been updated with the Simplified View of mediaFeature.  On the next call, I'd like to consider this the next official revision and promote this to the main proposal page.

The next call will be November 5.

The annotated agenda for the October 29, 2013 call

Since we discussed som many things and comments came in from email from folks whose schedules did not permit attendance before the call, I have copied the agenda and the major notes for the record. However, the major conclusions are reported above.

mediaFeature changes for review

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.

[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. Editor note: we did not drop it, but we also did not make any blanket statements implying other properties.

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.

[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] 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.

[CRM... outside the email thread]. How about if one was simply called mediaFeature and the other mediaAugmentation?

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

[CRM] I think that this needs discussion the next call. I'd say that textOnImage makes sense if it's the source content. However, if it's an augmentation (think of it like sign language) it counts as a mediaFeature. It's a tough call either way: I am concerned about adding a new term to the world of accessibility terminology though.

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. This can be found at http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker#Simplified_View_of_mediaFeature

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

Next items on the overall agenda

  • ATCompatible
  • ControlFlexibility and accessAPI (we'll be lucky if we get to this point on 10/29)
  • accessMode and the three proposals for the available access modes (this is a topic for a future call)
  • is/hasAdaptation

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.