[Accessforall] [Profiles] "User preference key" instead of"User ID"
Treviranus, Jutta (Academic)
jtreviranus at faculty.ocadu.ca
Sat Jul 7 14:54:29 UTC 2012
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.
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.
>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.
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 Clark
> Lead Software Architect,
> Inclusive Design Research Centre, OCAD University
> Accessforall mailing list
> Accessforall at fluidproject.org
More information about the Accessforall