[Accessforall] Needs & Preferences call today at 12:00 UTC

Liddy Nevile liddy at sunriseresearch.org
Tue Jun 12 11:48:40 UTC 2012

Replying again, Matthew, I say only that the sort of thing you point  
to are one of the reasons we are working so carefully on the  
architecture. So, as I understand it, yes - others are thinking about  
these ideas too and we are working to enable them.


On 12/06/2012, at 9:31 PM, Matthew Atkinson wrote:

> Liddy's reply (thanks!) pointed out to me that I need to make a  
> clarification regarding our approach (below), but it also gave me  
> the opportunity to ask a couple of questions more pertinent to the  
> current Match Maker agenda, so I will put those to you first...
> On 12 Jun 2012, at 11:49, Liddy Nevile wrote:
>> I think you are right in thinking that this sort of work should be
>> able to sit on top of what we are doing.
> I think that for the purposes of today's call I have the following  
> questions (if I may join):
> 1. Do you think that the current (and foreseen) architecture will  
> allow people like me to re-implement our capability-based stuff on  
> top?
> 2. Stepping back, there seems to be a use-case for the match maker  
> architecture that I am not sure is yet supported...
> Imagine you want to aggregate users' data (anonymously of course) so  
> that it would be possible to, e.g., say "Users on this OS and using  
> this application tended to like the following GPII preferences."  I  
> think this could be very helpful in bootstrapping people and solving  
> a key problem:
>    People are often not aware of, or are able to discover,  
> adaptations that could help them.
> The work of the likes of David Sloan and Peter Gregor at Dundee, as  
> well as many others at other institutions, shows this up as a key  
> issue.  People sometimes assume that ICTs are not as flexible as  
> they are, because they are used to inflexible real-world analogues.   
> Or perhaps they are too focussed on what they are doing and instead  
> attempt to "muddle through" rather than search for means (GPII  
> preferences, micro-ATs or classic ATs) that may help them in their  
> task.
> Therefore my question is: would the current architecture (as per the  
> wiki) support such central/federated storage of user data and  
> therefore aggregating it in order to make such suggestions, or is  
> this something you are going to move on to specifying, or is it  
> perhaps simply out of scope at this point?
> [ Clearly there's a difference between the infrastructure and the  
> *provider* of the infrastructure -- e.g. email protocols vs email  
> service providers -- but what I'm getting at is: is it a goal of  
> GPII to support this sort of aggregation, *if* the service  
> providers, and users signed up to them, consent? ]
>> Probably the interesting questions will be how is the best way to
>> provide the user with something better than they have asked for...but
>> we are very conscious of not wanting to think that we can solve
>> problems by classifying people by their disabilities - we are adamant
>> that what is done for a user is according to what they have asked  
>> for,
>> their stated requirements, not what we think might be their
>> requirements given their disabilities - not something we will know.
>> This latter rule comes about because we are determined to work with
>> people's requirements without assuming they can be determined from a
>> person's disabilities - which has not worked in the past and is
>> against our philosophy anyway.
>> Not sure if this helps?
> It does -- thanks -- though I think I should make a few  
> clarifications, as we're definitely on the same page as you with  
> respect to giving users control.
> 0. Capabilities -- as per the WHO definition -- are very fine- 
> grained (a disability, if present, may affect many capabilities).   
> Our work is focussed on mainstreaming accessibility so that it can  
> help people experiencing minor-to-moderate impairments or transient  
> environmental barriers.  Also, people could be experiencing multiple  
> such problems at a given time.  Capabilities are, therefore, at a  
> more fine-grained level than disability and are more generally  
> applicable to different types of situation and person (and devices  
> they may be using).
> 1. We're definitely in the same camp -- not trying to pigeon-hole  
> people but rather look at their own actions in adapting a system to  
> their needs to try to pinpoint where capability problems may lie  
> and, thus, where we might be able to suggest further appropriate help.
> 2. As such, our system is much more based on "suggestions" rather  
> than direct settings changes.  Sometimes, however, a user "always"  
> makes a particular change, in which case we would consider  
> instigating the equivalent change on a new platform.
> This (briefly) is our attempt to tackle the problem that users are  
> likely unaware of what is available to help them, as mentioned  
> above.  We feel that capabilities, rather than OS or application,  
> would be a much more accurate indicator of preferences.  Once again,  
> we're talking about preferences the user has already established  
> through their use of the system -- we're trying to make these  
> preferences more portable by using capabilities (because the gamut  
> of human capabilities will change *a lot* slower than the features  
> and settings of devices that we are using).
> I will close now, but thanks for the input so far!
> best regards,
> -- 
> Matthew Tylee Atkinson
> http://mta.agrip.org.uk/
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall

More information about the Accessforall mailing list