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.
We discussed the two basic types of mediaFeature and concluded that there was a third class needed
We then reviewed the other mediaFeatures.
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
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.
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)
- 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 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
- /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.
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
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.
--
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-pr...@googlegroups.com.
To post to this group, send email to a11y-metad...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.