[Accessforall] [Profiles] "User preference key" instead of"User ID"

Gregg Vanderheiden gv at trace.wisc.edu
Sat Jul 7 15:23:25 UTC 2012

On Jul 7, 2012, at 4:54 PM, Treviranus, Jutta (Academic) wrote:

> Not to belabour the point. Most definitely, all language must be from the user's perspective. The user experience or user interaction design to select the needs and preferences must also fit the context and the group of users. It would be very different for a kindergarten context vs. a banking context.
> The notion of labelling functions not users comes not only from values but from user feedback we have gathered over many implementations. There were two resounding aggregate results from the user feedback from Web4All, TILE, Transformable and now FLOE, repeated by users who would be classified as disabled and users who are not:
> 1. How wonderful it is that they don't need to explain or justify their needs and preferences, and
> 2. Strong, overwhelming support for a framing that did not label them as the problem but the fit of the ICT as the problem to be resolved, and a design that didn't immediately slot them into a set of functions based on a disability label. 
> Low vision is one of the most innocuous labels. It gets more troublesome when we get into things like learning disability, cognitive disability, etc. I'm not sure what we gain by using the label "low vision" versus "easier to see." We would lose the positive framing that sets this apart from a history of stereotyping. 

GV: I think we should look at things like "easier to see" etc and see if there is any way that we can solve all our problems that way.   If we can - or even come close - we should adopt that.    Of course consumers can do anything they want.     But we should strive to ensure that "we" are all included in "we".  And we don't have any "them".    
> I, personally, need the functions that would be associated with low vision now, but I wouldn't go to the choice low vision. My grandmother lived to be 107 but she knew what a Wiki was and maintained extensive email correspondence with friends and family all around the world. If you were to whip out the "granny" set or profile when she approached your desk, you would not leave unscathed. 

GV:  Did anyone suggest labeling things 'granny'?   Didn’t see that - but we certainly don't want to do that - except if we are trying to discuss their relationship in a family  -  and then it would be grandmother not granny  and we shouldn’t forget grandfathers. 

> From an international perspective (as Erlend pointed out), from an implementation perspective (primary school, vs. bank, vs. university) we will need to tailor our language to the user's perspective. This includes the engineers and techies for the inward facing interfaces, and the suppliers and producers for the user experiences they engage in. What we need agreement on is the meaning. The meaning conveyed by labelling the perceived disability rather than the functions/configuration/design on offer is that the user is the problem that needs to be fixed. What has set AccessForAll apart from the beginning is that we take the perspective that the onus is on the designers and developers to make the ICT fit the user not the other way around. 

GV:  There has a comment made that using broad categories would help do a rough cut on user preferences.  But I don't see anything there that couldn’t also be done -- or done better -- by using rough cut needs (e.g.'easier to read' ) instead.   I think we should create a set of broad user needs that people could pick from that would better focus.  

And -- to keep from asking lots of questions that would not be applicable (e.g. font size and contrast and line spacing etc to someone who is blind) we could also have them check things that are NOT helpful to them.

So it would be   
Might be helpful,  
Definitely would not be helpful,   
Don't know, show me. 

Do we have a list of items by the way?

Easier to read
Easier to hear
Easier to understand
Read aloud to me
Alternate mouse or different way to point
Alternate keyboard or different way to type
Presented in Braille
Presented in Sign


> Jutta
> On 2012-07-07, at 5:58 AM, Clark, Colin wrote:
>> On 2012-07-06, at 11:35 AM, Jim Tobias wrote:
>>> I think there's another dimension we should be taking into account, not just here but throughout our work -- the degrees of awareness, autonomy, experience, and confidence of the users. For many, perhaps most, of GPII's intended potential users, the best description of a good starting point would be "for people with low vision" because it's easy to understand and relate to, even if the generic settings will not meet all their needs -- the alternative of walking through all the continua and features is going to be off-putting. 
>> Good point, Jim. We've had good experience in practice, supported by user testing, using terminology that is simple and user-centric yet not specific to a disability, such as "Easier to see" and "Easier to read," etc. I think if we're thoughtful and do our UX design well (driven by interaction designers, not technical folks like many of us), we can find language that resonates with our users yet avoids the risk of labelling and categorizing.
>> Colin
>> ---
>> Colin Clark
>> Lead Software Architect,
>> Inclusive Design Research Centre, OCAD University
>> http://inclusivedesign.ca
>> _______________________________________________
>> Accessforall mailing list
>> Accessforall at fluidproject.org
>> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120707/6d3901ab/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7318 bytes
Desc: not available
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120707/6d3901ab/attachment-0001.bin>

More information about the Accessforall mailing list