Re: Proposed Set of Needs/Preferences for v1

Thanks James, very useful comments.
As a general principle there's no reason why they couldn't be broken out 
into booleans.  However, the reason for presenting them in this kind of 
structure has to do with communicating about them at a human level with 
organisations and web authors - there *are* relationships between them 
(for example all the ones about "visual" are exactly that, about 
"visual") and that's important information to convey to users and others 
trying to understand what goes on - not necessarily to programmers, but 
it will certainly set the scene for how they are thought of in my view.

On extensibility - this deliberately limits extensibility. What I was 
hearing from browser vendors was that they wanted something very tight 
where they knew exactly what values might be expected - and the thinking 
was that extensions should require a spec revision (certainly for V1) - 
I think its not a problem if a future version of the spec wants to add 
terms to a vocabulary, but it is very tight for now.  The property names 
are almost like namespaces and its also pretty easy to add new ones if 
needed.  I take your point that the finer granularity of boolean terms 
may provide more flexibility to extend in different ways but I don't 
think the lack of that is actually a real limitation because if 
something doesn't fit one can always introduce a new property to hold 
it.  I was considering including a "general" property for exactly this 
purpose but at the last minute dropped it to keep the number of 
properties down.

The other reason I don't think this vocabulary model (i.e. not booleans) 
is a real problem is because I honestly think this is the right 
organisation for them. That sounds bigoted but its from working with 
preferences about 12 years now and these have really become the accepted 
"categories" in user communities that talk about these things. For the 
most part they relate to human sensory functionalities (vision, hearing 
etc.) and I'm pretty sure they are correct and won't change in the 
timescales we are working in (not human-evolutionary timescales).  What 
I'm saying is these are accepted vocabularies in many accessibility 
communities.

I note your points about lower level preferences such as font-size and 
colours but I don't understand how in a world of multiple devices with 
various screen sizes and resolutions these can work.  My understanding 
is that the best place to make a decision about what fontsize to render 
something in is the device - because the device "knows" the 
characteristics that make particular sizes work. A need for 
"largerThanUsual" I can understand and could be responded to but 
particular font sizes I just cannot get my head around unless someone 
only uses one device and that preference is for that device alone.  The 
way I would see it a particular font size would be a solution to the 
need for "largerThanUsual".  Similar arguments apply to colour, contrast 
and probably other low level preferences.  We should talk about this to 
clarify different understandings I think - my view is these prefs need 
to have a level of abstractness to allow flexibility for different 
devices to respond in the way appropriate to the device.  There is 
thinking to do here on the browser-device interaction for cases where 
fonts are embedded in material.

I was planning to respond in detail to each point below but its already 
getting long and the quoting levels won't make it easy to see who said 
what so my suggestion is we go through your email here on the call 
because I think it will provide a very useful vehicle for discussing and 
clarifying many points.  If the model is accepted there is still plenty 
of work to do clarifying many things and going through the implications 
of each preference.

-andy (but don't ignore the below, just signing here for convenience)

> 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.
>
>
>
>



Cheers

andy
-- 
__________________
Andy Heath
http://axelafa.com

Received on Wednesday, 20 February 2013 19:17:08 UTC