Perspectives on usability and accessibility (from Whitney Quesenbery)

-------- Original Message --------
Subject: 	Re: Perspectives on usability and accessibility
Date: 	Mon, 22 Nov 2010 20:14:52 -0500
From: 	Whitney Quesenbery <whitneyq@wqusability.com>
To: 	Shawn Henry <shawn@w3.org>, shadi@w3.org

Shawn,

Feel free to share this with the EOWG with my name.

First, kudos for this document. It's something (several things, actually) that needs to be said, and it's great to see the WAI reaching out to connect the UX dots.

I have a couple of comments

In some cases, there are awkward wordings, and sentences that seem simply dropped in with little connection to the sentences around them. I'll detail some of those at the end. But, often, this awkwardness seems to stem from not having a really clear set of points this document wants to make.

Although I see your two points:
> 1. encourage those working in usability, digital inclusion, etc. to coordinate with existing WAI guidelines, WAI, and the accessibility field; and 2. clarify WAI's position that optimum accessibility is achieved with both standards and real people.

You might do better to say this more clearly up front, and discuss them separately. The second point, in particular, is not made very strongly. The first tends to say "you should just use what we've already done" but the second invites other professionals to bring their expertise to bear on improving the user experience of the web for all.

By the way, the plain language people are going through a similar transition. Where they started with technical writing guidelines, the Center for Plain Language has now adopted a behavioral model: that something is in plain language if people can find what they need, understand what they find and use it to meet their goals.

The second point similarly expands a view of accessibility be more than "meeting a set of technical guidelines" to "using those guidelines as the basis for understanding and meeting the needs of real people in real activities.


*Work of ISO to bring usability and accessibility together*
I also wonder why you haven't mentioned the work of the ISO committees revising and re-factoring the 9241 series. They've taken some significant steps, which are worth noting. Tom Stewart at System Concepts is the committee chair and can provide more information. He's written about this in a few public places, including a presentation at the G3ICT Forum 2008 in Geneva. They are bringing together all of the UX standards into the ISO 9241 family. This is primarily to create a clear relationship between them. Most importantly, ISO 13047 (A human-centred design process) and ISO TS 16071 will be moved.

As you know, the widely cited definition of usability is from 9241-11.
The definition of accessibility is (or will be? i've lost track of this progress) "the usability of a product, service, environment or facility by people with the widest range of capabilities."

I think this is essentially the same point that you make under "Including accessibility in usability research and practice" which would be strengthened if you acknowledged that people in HCI/UX/Usability are already moving in this direction.


*Definition of accessibility*
I think I understand the paragraph that starts "Some accessibility guidelines primarily meet..." but it's really jumbled.

Isn't this entire document about "meeting needs" - and doing so in a better way? I think you mean that some accessibility guidelines are focused on ensuring that the technical construction of the web does not create barriers, and actively supports people using assistive technologies.

Then you can go on to say that many accessibility guidelines can also improve access to the web for people, benefiting (your list of) people who may not be traditionally included under the rubric of accessibility.

Although I like your example, you need to explain why it's "good usability" to be able to use a site without a mouse.

This also raises a structural problem. You dive into this discussion of the relationship before you have defined usability. If you started with definitions and showed how they were related, all of this would flow more easily. More on this below.

*Definition of usability*
You are accurate that usability is defined by "efficient, effective, satisfying". But, I'd place it under user experience rather than HCI for the purposes of this document. Although you talk about research, most of what you discuss is practice. And it will let you talk about the combination of removing barriers (let's call this technical accessibility for the moment) and usability (stay on the narrow definition) informing a UCD process with the aim of creating web sites that are an excellent experience for everyone, including people with disabilities.

*Corollary benefits*
Not until you get to this point would I talk about the overlap between good usability principles and accessibility requirements. The obvious way to talk about this is that human experience is not binary, but on a spectrum of abilities. Then you can talk about the "everyone" who benefits. This is the place to make the point that many guidelines originally written with a narrow view of accessibility turn out to have much broader implications, making the web both more accessible and usable for a wide range of people.

Editorial nit: you don't "include" accessibility guidelines, you design to them or test to them or whatever.

Why not make the most obvious point. Although there is a lot of evidence for the validity of usability guidelines (see the usability.gov/HHS <http://usability.gov/HHS> Research Based Guidelines, for example), there are no laws or regulations requiring them. But there are laws requiring accessibility guidelines to be met. As you have shown, far from just affecting a small population, they can raise the usability of the web for all. As someone I worked with once said about writing procurement documents, "I can't require usability directly, but I can require things that are companions: coding to web standards, and accessibility."


*People with disabilities in usability and usability for accessibility.*
Now, you are ready to make your last set of paired assertions. Including people with disabilities (and older adults,.. and the rest of the list) has two benefits:

1. Considering accessibility and a broader audience early in the process and at evaluation improves products by including the people who are most affected by usability problems

2. Considering usability as you work towards accessibility ensures that you not only remove barriers, but actively consider the user experience of people who use different AT. Usability allows you to address the goals, not just the technical standards.


*WAI Guidelines*
This section seems particularly jarring - I'd just started to think about how the two practices inform and expand each other when I was thrown back a a list of WAI guidelines. I'd save this until the end.


*Working together..*
This is too important a point to leave it to the end.
The point I made in "More Alike Than You Think" and the premise of Caroline Jarrett's Design to Read project is covered in this section: that guidelines developed for one, focused group are often substantially the same as those for another. Sometimes, the reasons are different, even if the resulting guidelines are the same. It all comes down to understanding the people and how they interact with technology.

Although I agree that lack of coordination can lead to confusing and conflicting results, it seems a little harsh to blame people researching older adults for not considering WAI guidelines. Why not acknowledge that although the original scope was fairly narrow, WAI itself had broadened its vision to understand how accessibility requirements can benefit other groups.

(This may be my only rant: as you know, in comments on the voting system guidelines we took a lot of criticism for moving some things that are traditionally "accessibility requirements" into the general requirements. So, there's a need for a broader view by all.)

A few of the thoughts from the end of this section would be useful in the introduction. It would make this less of a surprise ending, and help place the rest of the document in context. Because, in the end, you call for:

- Research support for accessibility requirements
- Understanding of how the user context or specific design approaches can affect accessibility
- Harmonization, by using accessibility guidelines as the basis for design guidelines



You've tried, but could be more clear about the difference between accessibility guidelines:

- that support assistive technologies (ALT tags, and other coding requirements)
- that ensure that there are features or capabilities present to allow users to personalize the interface, or interact with the product in their own way (text sizing, timeouts)
- that address usability issues that can become barriers for people with specific disabilities (plain language, for example)

It might be too hard to make this point, but I talk about it with teams as things you have to do to make sure everyone can use your product at all first, and then things that make it difficult or confusing to use. This sometimes lines up with things you do in code and approaches to design.


Hope this helps.

...

Whitney Quesenbery
whitneyq@wqusability.com <mailto:whitneyq@wqusability.com>
908-617-1122 | Twitter @whitneyq | www.WQusability.com <http://www.WQusability.com>

*Storytelling for User Experience*
blog: www.rosenfeldmedia.com/books/storytelling <http://www.rosenfeldmedia.com/books/storytelling>

Received on Wednesday, 24 November 2010 19:26:41 UTC