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

a bunch of good comments, IMHO :-)

Liddy

On 29/10/2013, at 1:41 PM, Madeleine Rothberg wrote:

> My apologies to all. I won't be able to meet this week. Here are  
> some of my opinions in response to Chuck's questions.
>> 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)
> [MR] I like transformable — it is the most explanatory. But is it  
> too much jargon? Is there something even simpler we haven't thought  
> of? How about flexible?
>
>> 	• 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.
>
>> 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.
>
>> 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 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.
> [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.
>
>> 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.
>>
>> 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.)
>
> Again, I'm sorry to miss tomorrow's call. I hope it is productive  
> and I look forward to seeing the notes.
>
> -Madeleine
>
> --
> Madeleine Rothberg
> Project Director
> Carl and Ruth Shapiro Family National Center for Accessible Media at  
> WGBH
> http://ncam.wgbh.org
> madeleine_rothberg@wgbh.org
> P {margin-top:0;margin-bottom:0;}
>
> -- 
> 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.

Received on Tuesday, 29 October 2013 10:55:11 UTC