[Accessforall] Needs & Preferences call today at 12:00 UTC
M.T.Atkinson at lboro.ac.uk
Tue Jun 12 11:31:14 UTC 2012
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!
Matthew Tylee Atkinson
More information about the Accessforall