This line was removed.
This word was removed. This word was added.
This line was added.
Changes (8)View Page History
|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.
|*# 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 not reach a consensus on the choices above and I need to have something to go forward with. I will change the specification to reflect #4, mediaFeature. We 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, if it changes at all, 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 (although I'll admit that tactile.haptic does not fit the syntax that AfA has used for refinements). 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 |
|** /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 the next call, I'd like to consider this the next official revision and promote this to the main proposal page. |
|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. |
|* 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 her 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)
|*** pitch: high, low or contrast as an extension |
* Liddy also suggested a new property value for controlFlexibillity
|** timing is a 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