Minutes from the Accessibility Metadata working group call on October 29… The next call will be November 5

We made significant progress on the comments that came in on mediaFeature, even if we had only a small set of people on the call.

I've attached the conclusions below, which have been updated in the issue tracker, all in the mediaFeature question.

The full notes can be found on our wiki at https://wiki.benetech.org/display/a11ymetadata/Minutes+10-29-2013
The agenda for next week should be available shortly.
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
     *   mediaFeature (within access mode), mediaAugmentation (cross access mode)
     *   mediaFeature (within access mode), accessFeature (cross access mode)
     *   accessFeature as the new name for all three classes, and we describe them in sets
     *   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<http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker#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.