Re: [a11y-metadata-project] Minutes from the Accessibility Metadata working group call on October 29… The next call will be November 5

I'm also supporting option #4, the status quo, on mediaFeature for the following reasons:

1) Developers are not going to remember, which one to use. Less is better. A principle we agreed on at the beginning was that AfA was to complex for the web and we needed to simplify to maximize adoption by webmasters/web developers.
2) In the spirit of #1 as previously discussed mediaFeature is a more general term and expandable to other use cases, thus supporting #1 above.
3) For understandable reasons this debate could go on forever and we spent 4+ months on it prior to the deadline to our funder. In the spirit of good software development, let's ship the spec a broad and competent group of people agreed upon at that deadline. Let's learn from what actually happens in the early phases of adoption and adjust.

>From attending and presenting at EDUPUB this week, there is significant industry excitement about this work and they need it now. Let's not loose a valuable opportunity.

https://twitter.com/wilm/status/395643644356853760

Gerardo

Gerardo Capiel
VP of Engineering
Benetech

On Oct 31, 2013, at 6:50 AM, "Charles Myers" <charlesm@benetech.org<mailto:charlesm@benetech.org>> wrote:

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.

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