User context use cases

I've made a start on the use cases but not finished.
They are in the second half of

http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements

My personal view is that there is a strong case to ensure the 
preferences we model (at some point, not necessarily all in V1) provide 
matching to the Metadata in the a11ymetadata/schema.org work, which 
until very recently was this

http://www.a11ymetadata.org/the-specification/

Unfortunately that group have at the very last minute been discussing 
some changes that may not be trivial. My hope is that will settle down 
quickly and I think it will, but it is at the moment a moving target.
The IMS AfA 3.0 working group discussed a few weeks ago folding back 
into the IMS spec the changes that have been made in the a11ymetadata 
work.  If this is going to work well then for me, interoperability 
across those groups is key. However that's its not so easy to hit moving 
targets.

The version of the a11ymetadata work currently under discussion in that 
group is in the large table half way through this page

http://www.w3.org/wiki/WebSchemas/Accessibility/Issues_Tracker#What_is_the_goal_of_mediaFeature.3F_.28conforming_or_informational.29_Do_we_have_this_right.3F

but its not yet stable. Bear in mind also that what we are doing is 
preferences and that work is Metadata - we need to be able to match the 
two together but its not necessarily one-to-one.

Here's what I've done in our use cases so far.  I've done the first 7 
with full description.  The rest I've taken from the accessMode and 
mediaFeatures vocabularies in 
http://www.a11ymetadata.org/the-specification/ but I've excluded, for now,

colorDependent
textOnImage
tactile

I think colorDependent should be a preference ("I don't want color 
dependent content").  I think there is a case for tactile as a 
preference (mobile devices that vibrate) but I don't have any good ideas 
how to handle textOnImage (as a preference).

For each of the accessModes, as preferences they appear in pairs which 
indicate a "this for that" substitution or augmentation. Thus e.g. 
textForAuditory.  All combinations from textual, visual, auditory have 
been given use case space but not all can occur in practice.

For each of the mediaFeatures I've included a use case space but not yet 
for all of them worked out the text that is needed to describe it. There 
are several different types. Some of them indicate interface settings or 
things like switching on a feature in the user agent, some content 
adaptations. In the IMS model preferences for these, where they indicate 
a media type they can occur with an accessMode meaning "for that 
accessMode give me this mediaType" but they can also occur alone, 
meaning "give me that media type".
Again, some of these will not be relevant but I've chosen for now to put 
them in so we can decide.  If anyone spots one that obviously cannot 
occur please edit it in the wiki to mark it that it cannot occur.

I have yet to check through IMS AfA 3.0 again and see if there are any 
preferences there for which there are not yet use cases space on the 
wiki. And I'm thinking about how to handle textOnImage and proposed 
terms in a11ymetadata of mathOnImage, chemOnImage, musicOnImage. I note 
that mathOnImage is such a common occurence that we might give thought 
to what might be the preference to match it (by definition, if they put 
maths on an image they probably didn't also put mathML).

This is a start on my action item but I don't have a clue what number it 
is.  I will continue it.

andy

> This is based on my action item to review ISO 24751 for potential requirements
> of interest in the User Contexts work.
>
> ISO 24751 enables the priority of each need/preference to be asserted. More
> specifically, it distinguishes needs (which must be satisfied for a resource
> to be accessible to the user in a given situation) from preferences. Optional
> and prohibited adaptations are also distinguished, but I think the most useful
> distinction is that between "required" and "preferred" items.
>
> Our User Contexts API, as currently drafted, treats all needs and preferences
> equally, whereas application authors might want "hard" requirements (i.e.,
> needs) to be distinguished from preferences.
>
> I don't think this issue can be easily resolved in isolation from use cases
> and the wider questions currently before the group regarding what should be
> included in the User Contexts specification. It is, however, a design decision
> that should be made deliberately and with an understanding of its
> implications.
>
>
>




andy
andyheath@axelrod.plus.com
-- 
__________________
Andy Heath
http://axelafa.com

Received on Wednesday, 16 October 2013 19:52:59 UTC