Re: Proposed Set of Needs/Preferences for v1

On Feb 6, 2013, at 6:30 AM, Andy Heath <AndyHeath@axelrod.plus.com> wrote:

> Each preference property instance consists of a (space-separated unordered) list of tokens taken from a strict vocabulary for that property.  For example the preference 

Relying on a strict token vocabulary is not very extensible. Would you consider a value of "foo" to mean "true" or "false"?

> textualForAuditory
> 
> indicates a user wishes auditory resources to be replaced by or augmented by textual resources.  This may be done in different ways depending on the media context.  Its values are a list drawn from the vocabulary:
> 
> (true false captions transcript transcript-simultaneous)
> 
> If the property has a value of '(true)' this is to be interpreted as a general requirement and a textual form delivered that is appropriate for the media concerned drawn from other tokens in that vocabulary as appropriate to the media context.  A value of (captions)  or (true captions) is to be interpreted as that the user wishes for audio to be accompanied by captions. It implies that the property is true and an intelligent system might infer that if captions are not available but a transcript is then this might be useful to deliver instead even though the user has not requested it explicitly.  The token 'false' must occur alone so a list of tokens containing 'false" and any other value is undefined (this includes '(true false)'.  The application should provide the best match to the user's preferences.

Is there any reason not break these up into more discrete boolean properties? This would seem much more clear to me as an author, and would allow for cleaner manipulation since you wouldn't need to parse a bunch of token lists; you'd only inspect the properties for which you could provide accommodation.

	Boolean 	captions (see subtitles and subtitleLanguage below)
	Boolean 	transcriptSimultaneous
	Boolean		transcript

And we'd probably also want:

	Boolean		subtitles (may supersede 'captions' pref if we can include SDH (with lang) or CC as options)
	LangList		subtitleLanguage (e.g. en-sdh, en-cc, en-us, en-uk, en, es-mx, es)
	FontSize	subtitleFontSize
	ColorL		subtitleFontColor
	Color		subtitleBackgroundColor
	ValueList	subtitleFont (e.g. helvetica, sans-serif)

I also removed the dashes (e.g. transcript-simultaneous became transcriptSimultaneous) so that these can be used as properties in JavaScript without being interpreted as subtraction operations.


> 1.2 Organisation of Preference Properties
> 
> Properties are described in terms of the modalities to which they relate. There are two kinds:
> 
> 	• Properties that relate to delivery of a specific modality - for example highContrast relates to a visual modality.
> 	• Properties that relate a preferred modality to an existing one and optionally give specific adaptation types that are preferred.

The categorization seems more useful if it's used to limit privacy access. In other words, a user agent may need to want the user when the web app accesses any information related to media alternatives like subtitles, but it shouldn't have to warn the user of every property being accessed.

> Where a property preference is for one modality over another delivery may be augmenting the one modality with another or replacing it depending on the best match to the user's context, which may be determinable from other preference settings. For example a user may specify that they prefer auditory information be delivered in textual form with the setting

I am unable to determine what this first sentence means.

> Each property instance has a value that consists of a list of tokens as specified in the definition of properties. Each token has an optional list of refinement parameters where such is meaningful.
> 
> 1.2.1 Interpretation of values
> 
> [Editors note: This needs a little careful work to tighten it - for example for some vocabulary (true false X Y) is the instance (true) equivalent to (X Y) ? ]
> 
> Lists of values may not be logically inconsistent. In particular the following are prohibited and if they occur are undefined:
> 	• Any list of values containing both true and false
> 	• Any list of values containing false together with any other value (i.e. false must occur alone)
> 	• A list of values consisting of (true X) should be considered equivalent to (X)
> Where a list of values contains true and any other values the other values should be considered as refining the value true (i.e. providing more detail of what is preferred). A system responding to the value for some property of

This seems to confirm my point that discrete boolean values would be better than token lists.

> might make intelligent inferences about media that might be useable by that user in that context.  Where a vocabulary contains terms (true, false, X, Y) and an instance of a property is either (true, X) or just (X) a system would ideally deliver an X if it is available but if an X is not available then the system might infer that a Y would be useful and deliver that instead.

I think preference order should be second property rather than be combined with 

e.g. subtitles

	Boolean		subtitles (may supersede 'captions' pref if we can include SDH (with lang) or CC as options)

This indicates a simple on/off setting.

	LangList		subtitleLanguage (e.g. en-sdh, en-cc, en-us, en-uk, en, es-mx, es)
	
This indicates that the user wants their captions in a particular preference order.

1. English subtitles for the deaf and hard of hearing (SDH).
2. English closed captions (CC).
3. American English subtitles.
4. British English subtitles.
5. Any other form of English subtitles.
6. Mexican Spanish subtitles.
7. Any other form of Spanish subtitles.


> 1.3.1 auditory
> Indicates a preference for auditory resources
> true Prefer auditory resources
> false Default value - no preference

This is too vague. Is this meant to be about audio descriptions for video? If not, what is it in reference to?

> 1.3.2 textual
> Indicates a preference for textual resources
> true Prefer textual resources
> false Default value - no preference

This one is also too vague. 

> 1.3.3 visual
> 
> Indicates a preference for visual resources
> Token Values
> Description
> true
> Prefer visual resources
> false
> Default value - no preference
> highContrast	Where visual is the preferred modality the preference is for presentation of text and images of text that has a contrast ratio of at least 4.5:1, or, for larger text, a contrast ratio of at least 3:1 (WCAG2 Checkpoint 1.4.3):
> http://www.w3.org/TR/WCAG20/#visual-audio-contrast.
> blackOnWhite	black text and borders on a white background
> whiteOnBlack	white text and borders on a black background
> inverseVideo	Text, image and video colors reversed

These last few might get confusing. For example, most interfaces today default to dark-on-light color palettes, but what does it mean when that is combined with an "inverted colors" preference. Some authors would see this as being the same as having a light-on-dark color palette preference without the inversion. I don't think those are equal, so we would need a note to indicated "darkOnLight + invertedColors" is not equal to "lightOnDark" and vice versa. Better yet, lightOnDark could just be a boolean where the false value implied dark-on-light.

It's unclear where you think the division lies between "preferred preference" and "actual preference" I'd recommend we stick to actual preferences for version 1.0.

	Float		contrastFactor (e.g. 0.0 - 1.0 where 0.0 is "no adjustment" and 1.0 represents the most contrast possible)
	Boolean		grayscale
	Boolean		invertedColors
	Boolean		lightOnDark 


> 1.3.4 tactile
> Indicates a preference for tactile resources
> true Prefer tactile resources
> false Default value - no preference

I think "tactile" preferences are outside the scope of our working group charter, and these preferences are probably not implementable in any useful way. If you have something specific in mind, please share your example.


> 1.3.17 languageOfAdaptation
> 
> Indicates a preference for adaptations to be delivered in a particular language. Note that this may not be the same language in which the user operates the device.
> Token Values	Description
> Internal Language Code presented to user as string or selectable widget	TBD: get IETF reference
> undefined	Preference is for adaptations to be delivered in the default user language for that device

I think we'd want separate lists for each modality because, for example, a user may prefer English audio with Spanish subtitles, or English audio with English subtitles.

> 1.3.18 hazard
> 
> Indicates characteristics of resources that a user DOES NOT wish to receive because of potential hazards for that user. Note also that the meaning of a value of true without any other value is undefined for this property (i.e. it must have a refinement to be meaningful)
> Token Values	Description
> false	Default value - no preference

> flashing	A preference that a resource having a visual pattern that flashes more than three times in any one second not be delivered to the user. Note that this level of flashing can cause seizures in some users (WCAG2 Guideline 2.3.1 A):
> http://www.w3.org/TR/WCAG20/#seizure].
> flashingStrict	A preference that a resource having a visual pattern that flashes more than three times in any one second not be delivered to the user. Note that this level of flashing can cause seizures in some users (WCAG2 Guideline 2.3.1 AAA):
>  http://www.w3.org/TR/WCAG20/#seizure

Unless I'm missing something, there is no difference between the description of these properties.

> motionSimulation	A preference that a resource simulating motion not be delivered to the user. Note that for some users such a resource may induce nausea
> sound	 Prefer that resources generating an audio pattern that can cause the user to have seizures [ISO 29138] not be delivered to the user.

Sound is too vague. This should be split into separate prefs, but I wonder they can be specified in a discrete enough way to be implemented in a useful manner.

For example:

	Boolean		avoidVisualFlashing (Everyone should be doing this anyway. Why do we need a preference?)
	Boolean 	avoidMotion? (What does this mean? Does it mean the same thing to everyone?)
	Boolean		avoidCertainSounds? (What does this mean? Does it mean the same thing to everyone?)


> 1.3.19 ATInteroperable
> Indicates that where possible resources that are interoperable with AT should be selected. Note that the default for this preference unless otherwise defined is true.

Too vague. There are many kinds of assistive technologies.

> 1.3.20 simplePresentation
> Indicates a preference for very simple presentation of interface and content even if the device supports more complex presentation (for example if the device large or high-resolution screen)

Too vague. "Simple" means something different to everyone who hears the term.

Received on Wednesday, 20 February 2013 00:20:07 UTC