Re: [a11y-metadata-project] The next Accessibility Metadata call will be at 9:00 AM PDT on 10/29 to try to wrap on mediaFeature

I just wanted to let people know that I created the simplified view of 
the mediaFeature property., taking into account what most of the items 
in the minutes from last week and deduplicating the extensions.  I also 
added, for the content or augmentation, the detail of which access modes 
are intellectually brought to new access modes.

http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker#Simplified_View_of_mediaFeature

This may help with context before the call.

On 10/28/2013 2:15 PM, Charles Myers wrote:
> And we have an action-packed agenda.  Last week was a deep dive into 
> the finely divided and extended mediaFeature.  It took a while more 
> than I expected to write up the minutes, but they are done now.  As 
> they're long, here is the link 
> https://wiki.benetech.org/display/a11ymetadata/Minutes+10-22-2013
>
> Tomorrow's call will be focused on getting the last issues on 
> mediaFeature and accessMode refinements behind us.  Since most of the 
> agenda is a review of last week's minutes and making the decisions in 
> bold, I've copied the agenda below.  Your thoughts on the bold items 
> are your homework.
>
>
>       mediaFeature changes for review
>
> We had significant discussions around textualTransformFeature and 
> visualTransformFeature. It's worth noting that the primary concepts in 
> WCAG 1.4 <http://www.w3.org/TR/WCAG20/#visual-audio-contrast> 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
>     <http://www.w3.org/TR/WCAG20/#content-structure-separation> 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
>       o /caption
>       o /signlanguage, which can be followed by the ISO 639-2 language
>         code (reference
>         <http://www.evertype.com/standards/iso639/sign-language.html>,
>         although I am sure that someone could find something more
>         authoritative), such as /sgn-en-us
>       o *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 <http://www.w3.org/TR/WCAG20/#visual-audio-contrast>.
> I propose that we add a auditoryTransformFeature of
>
>   * enhancedAudio, which can then have one of three extensions
>       o /noBackground
>       o /reducedBackground (the WCAG concept 20 dB)
>       o /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)*
>       o */iconOnImage*
>       o */diagramOnImage*
>       o */chartOnImage*
>
> -- 
> 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.
> To post to this group, send email to 
> a11y-metadata-project@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.