<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br><div><div>On Jul 7, 2012, at 4:54 PM, Treviranus, Jutta (Academic) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>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.<br><br>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:<br>1. How wonderful it is that they don't need to explain or justify their needs and preferences, and<br>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. <br><br>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. <br></div></blockquote><div><br></div><div><br></div><b><font class="Apple-style-span" color="#006d08">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".    </font></b></div><div><b><font class="Apple-style-span" color="#006d08"> </font></b><br><blockquote type="cite"><div><br>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. <br></div></blockquote><div><br></div><div><b><font class="Apple-style-span" color="#006d08">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. </font></b></div><br><blockquote type="cite"><div><br>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. <br></div></blockquote><div><br></div><div><br></div><b><font class="Apple-style-span" color="#006d08">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.  </font></b></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b>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.</b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b>So it would be   </b></font></div><div><ul class="MailOutline"><li><span class="Apple-style-span" style="color: rgb(0, 109, 8); "><b>Might be helpful,  </b></span></li><li><span class="Apple-style-span" style="color: rgb(0, 109, 8); "><b>Definitely would not be helpful,   </b></span></li><li><span class="Apple-style-span" style="color: rgb(0, 109, 8); "><b>Don't know, show me. </b></span></li></ul></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b>Do we have a list of items by the way?</b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><ul class="MailOutline"><li><font class="Apple-style-span" color="#006d08"><b>Easier to read</b></font></li><li><font class="Apple-style-span" color="#006d08"><b>Easier to hear</b></font></li><li><font class="Apple-style-span" color="#006d08"><b>Easier to understand</b></font></li><li><font class="Apple-style-span" color="#006d08"><b>Read aloud to me</b></font></li><li><span class="Apple-style-span" style="color: rgb(0, 109, 8); "><b>Alternate mouse or different way to point</b></span></li><li><span class="Apple-style-span" style="color: rgb(0, 109, 8); "><b>Alternate keyboard or different way to type</b></span></li></ul></div><div><ul class="MailOutline"><li><font class="Apple-style-span" color="#006d08"><b>Presented in Braille</b></font></li><li><font class="Apple-style-span" color="#006d08"><b>Presented in Sign</b></font></li></ul><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b>Gregg</b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font></div></div><div><font class="Apple-style-span" color="#006d08"><b><br></b></font><blockquote type="cite"><div><br>Jutta<br><br><br><br>On 2012-07-07, at 5:58 AM, Clark, Colin wrote:<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On 2012-07-06, at 11:35 AM, Jim Tobias wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">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. <br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Colin<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">---<br></blockquote><blockquote type="cite">Colin Clark<br></blockquote><blockquote type="cite">Lead Software Architect,<br></blockquote><blockquote type="cite">Inclusive Design Research Centre, OCAD University<br></blockquote><blockquote type="cite"><a href="http://inclusivedesign.ca">http://inclusivedesign.ca</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">Accessforall mailing list<br></blockquote><blockquote type="cite"><a href="mailto:Accessforall@fluidproject.org">Accessforall@fluidproject.org</a><br></blockquote><blockquote type="cite"><a href="http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall">http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall</a><br></blockquote><br></div></blockquote></div><br></body></html>