- From: Liddy Nevile <liddy@sunriseresearch.org>
- Date: Tue, 29 Oct 2013 21:54:30 +1100
- To: Madeleine Rothberg <madeleine_rothberg@wgbh.org>
- Cc: "a11y-metadata-project@googlegroups.com" <a11y-metadata-project@googlegroups.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
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