Minutes from the Novermebr 5, 2013 Accessibility Metadata Working Group call

We had another action-packed working group call yesterday, with a set of tweaks and name changes applied to the properties and values. We also have taken greater advantage of the extension mechanism on property values to keep the vocabulary smaller and more manageable.

I've copied the notes below, and they are available on our wiki.  See https://wiki.benetech.org/display/a11ymetadata/Minutes+11-05-2013
Note that these minutes are the union of October 29 and November 5, as we reviewed and refined October 29 minutes in this meeting.

The next steps are that I'll be editing this into the next version of the specification in the next few days. Be on the lookout for more announcements.

November 05, 2013 9:00 AM PDT
Minutes

Andy Heath
Liddy Nevile
Charles Myers
Anastasia Cheetham
Madeleine Rothberg
Gerardo Capiel

Review of Conclusions from previous October 29 call

We reviewed the conclusions from the last call (since we added Gerardo and Madeliene to the call), all revolving around coming to a conclusion and consensus on mediaFeature. There was great backing for this from eduPub, as there was a serious desire to add this metadata into the epub specification. Also, Gerardo and Markus Gylling will be meeting with Charles McN at the W3C Tech Plenary in hopes of making some significant progress on this.

I am copying the status from the last call (so that there is one place where all the changes are listed), but adding the new conclusions or changes in bold. These minutes supercede those from the October 29 call. The topics 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
  *   On November 5, we decided to rename the property to be accessFeature. The dominant reason for this is that it puts it closer to accessMode and accessHazard in schema.org, which is a great boon. Choice #3 won out. 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 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 as an extension, e.g., tactile/haptic
  *   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")

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 November 5, we decided that these changes have reached a point where we should declare the next version (V.6) of the specification and make it known publicly. That editorial work will happen over the next few days and will be published before the weekend.

There is NO call scheduled for November 12. We may have open calls on Wednesday and Thursday this week to prepare/refine our content for the meetings in China next week. The schedule is open at this point.

New issues on mediaFeature/ accessmode refinements and other properties

  *   The proposal floated in the last meeting of /alternativeImage was decided against. In its place, we're going back to
     *   signLanguage as a property value, which can be followed by the language code. This is always, of course, a visual property
     *   The concept that had been floated for treating an open caption as alternative Image was nixed, as it was a bit too esoteric. Instead, we decided that there would always be the property value of captions, which could have two extensions, /text (for ones that were done as plaintext that could be presented in multiple forms and processed in a variety of ways) and /visual (for ones that were burned into the video visual presentation). If no extension was present, it is assumed that it would be captions/visual, as this is how most people think of captions.
  *   We reviewed Liddy's contributions in the spreadsheet and the proposed new properties that could be added under accessFeature. These were discussed, but not acted upon, as there were open items on all of them
     *   imageSize (fixed or variable) - Charles N (screen size, reflowable, interaction) certain resources can't really be scaled... would like a reference). Gerardo will talk to Charles N in China. This can be added, but it would be great to have a WCAG or WAI-ARIA reference to base this on.
     *   A number of enhancedAudio features were discussed. Our conclusion was that we did not have an audio/auditory expert on the team and nobody has stepped up yet. Many of these new proposed property values seem closer to being attributes of the audio itself (which may lend to more or less accessibility for different users) that enhancements for accessibility). (Note that we did decided that the enhancedAudio attribute proposed last week, based on WCAG 2.0 section 1.4 did make sense to move forward with)
        *   tone: musicAlternative or toneDiscriminationAlternative as extensions
        *   voice: voiceDiscriminationAlternative, selectedVoice or contrast as extensions
        *   volume: loud or quiet as extensions, with the possibility of variable as a second level extension.
        *   pitch: high, low or contrast as an extension
  *   Liddy also suggested a new property value for controlFlexibillity
     *   timing is the new property value, which means that the timing is variable and can be altered/ stretched for interactive pages, which fall under softwareApplication.
     *   We also discussed better names for controlFlexibility.
        *   controlFlexibility - pro: more explicit: it's about how the control is flexible, not just how it can be controlled
        *   control: pro: shorter, less verbose
        *   accessControl: fits with other access properties
     *   Gerardo will discuss this further with Charles McN in China, but we will be changing the name to accessControl and adding timing as a value now.
  *   We completed the discussion on whether whether the refinements of visual in accessMode should be "OnImage" or "OnVisual," referring to the access mode. We concluded that the change to OnVisual made more sense, so the specification will be updated for this.
  *   We also concluded that we could add new refinements as well, primarily to incoprprate the properties used in the DAPP project.
     *   /diagramOnVisual
     *   /chartOnVisual

Next items on the overall agenda

  *   ATCompatible
  *   accessControl and accessAPI
  *   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.