Re: User Contexts: identifying assistive technologies

Thanks Jason, comments inline -
<snipped for reasons of brevity, focus and thread-depth-confusion>

> I agree, naturally, although it isn't clear that the privacy implications of
> this proposed item (i.e., identification of assistive technologies) are much
> different from those of combinations of some of the other proposed items. For
> example, if a user declares a need for, say, auditory descriptions of video,
> descriptions of images, etc., then this is most likely because eyes are
> occupied or the user has a vision-related disability, with the latter being
> more probable. If the user logs into a Web-based account from different user

I disagree that the latter is more probable.  That may be the case at 
the moment but audio descriptions of video are still expensive to 
produce - but getting cheaper and will continue to - I think there will 
be more uses of "alternative" media (maybe we should just think of them 
as multiple information streams not "alternative") for non-disability 
use cases than for disability ones as the market grows.  I have normal 
vision but if auditory descriptions of video were more widely available 
I'd often use them to "watch" videos while I do other things such as 
make a cup of tea, travel on the tube etc. - so many informational 
resources are being produced in video and its a productivity hit to have 
to focus on visual a machine to consume them.  This applies even more to 
other modality adaptations.

> agents and different IP addresses while retaining these preferences then we
> can infer with an even greater level of assurance that there's a disability in
> play.

What can be determined by looking at context is a serious issue for the 
whole industry but I think its not a reason to give up and just assume 
that whether someone has a specific disability can't be kept a secret - 
it has to be solved because it won't be long before bank accounts are 
hacked using this kind of information.  The broader point is it isn't 
*necessary* to know and that's a good thing because it enables us to not 
consider someone in a category of persons.  Why someone uses a 
particular form of interaction in some context just isn't our business - 
and if we can devise technological approaches that hide that information 
that's a good step - the fact that it isn't sufficient to guard privacy 
isn't a reason not to do it - if we do what we can, some issues are 
beyond our scope and are for others to address (privacy across contexts 
may be a more general issue than accessibility - but I don't know). 
This seems to have become a discussion around privacy, which is not a 
bad thing as we need to have that discussion anyway.

>
> Thus for practical purposes, outright declaring the presence of a screen
> reader in this scenario isn't going to tell the Web site operator much that
> wasn't already known. While I agree that there are privacy implications, the
> same applies for many of the other items which is why the user needs to be
> able to exercise control with respect to disclosure of most of the profile.

This seems to mix two arguments that don't mix.  Large granularity of 
privacy doesn't protect the user because the web site operator needs to 
get at each preference anyway (which suggests we need small-ganularity 
privacy).  Declaring the presence of a screenreader *does* tell them 
stuff that wasn't known because we may develop ways to block undesirable 
cross-context reasoning by which the web site operator can "get to know 
this anyway". I admit its a hard problem to devise a way to permit some 
cross-context reasoning (which is desirable) and block other kinds 
(there are solutions but they aren't so nice).

The other question is what kinds of devices and business-model-policies 
are we thinking about this applying to - I can't imagine a screen-reader 
operating with a mobile device having built-in audio-rendering of 
content because screen-readers have traditionally been produced by 
third-party software houses.  Is that the best way to address 
audio-rendering in an API running on a device that has this ? (its a 
serious question not a rhetorical one).

I hope this "debate" is useful - at least we will have aired some issues 
around it whatever approach we choose.

andy
>
>
>




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

Received on Tuesday, 4 June 2013 11:23:31 UTC