Re: Collecting requirements for User Contexts

Thank you, Andy, for the review - see comments inline below.
Andy Heath <andyheath@axelrod.plus.com> wrote:
> >* Assistive technologies (via available API calls).
> 
> I'm not sure about this but it may be because I am not interpreting
> your words in the way you intend.  My understanding is its not a
> good idea to identify the assistive technologies people use in
> preferences.  
 
 I think this issue is identified in the editorial note to the screen reader
 and assistive technology section. It should also be recalled that we aren't
 at the point in the process of excluding items yet, and also see the
 qualification below.
> I may have misunderstood what you meant here, my apologies if I did
> but for me its very important that the "this modality for that one"
> is part of this because its the fundamental idea.

There are really two issues:

1. Whether the user agent can query active assistive technologies via an as
yet non-existent but presumably implementation-defined  API to obtain items
for inclusion in the user's context. I don't think this possibility should be
excluded a priori.

2. Whether the user agent can disclose the identities of active assistive
technologies as part of the context. This is a separate matter, addressed in a
later section of the requirements.
> >[Editorial note: should there be a hierarchy of sources, e.g., the
> >user's explicit preferences override information gathered from the
> >environment, or should this be left completely unspecified? It is
> >undecided whether needs/preferences not readily available from the
> >first two items above (and possibly also the assistive technology
> >item) should be excluded from the first version of the specification.]
> 
> This is interesting and difficult imho.  Different devices/vendors
> might want to implement different internal algorithms (as unique
> selling points) but I don't think either takes precedence - more a
> case of matching the two together.  So a particular delivery
> presentation might be what is best for a particular context with a
> particular preference (consider contrast/font-size/brightness with a
> phone walking along in changing light conditions - there are
> different ways a device might optimise its delivery).  This *is* new
> ground - but the expectation should be in my view that we model
> environmental and preferences in the API/data model in a way that a
> device can both choose and report what adapations it makes.  A web
> app would need to know what environmental information is available,
> what preference settings are known and what has already been done. A
> device might decide not to report some of those things it considers
> it has already taken account of - this needs verbal discussion to
> carefully capture everything.

I agree this is difficult; the point at which it becomes a significant issue
for standardization, in my view, is where the question arises of a user
override - whether explicitly configured preferences should take precedence.
This could of course be left to the good judgment of implementors if the risk
of problematic decisions in this area is considered minimal.
> 
> I need to check this for completeness but it seems to capture my
> earlier argument but I will leave that there because it may help us
> sing from the same hymn-sheet.  The only serious issue here for me
> is how far we support modelling of specific AT in preferences (such
> as screenreaders) tied in with what kind of devices are in our
> scope.

It would be very helpful at this stage if you could search for unintended
omissions from the requirements. I tried to capture everything in your
proposals but I may have overlooked some items or misinterpreted them.

Received on Tuesday, 4 June 2013 10:14:35 UTC