Thread Subject: Re: about the word usable

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: Whitney Quesenbery
Date: Mon, Feb 05 2007 7:00 AM

Jim,

This is a great way to think about designing an interface. I've also seen
it used to organize a standard for a specific product or class or products,
for example a detailed product or platform style guide.

It's harder to use for a very broad and general standard. I've tried, and
for some of the categories, you end up with requirements that are so broad
that they are hard to test. For example, even in the VVSG - focused on a
single type of product, with a well-defined task, we ended up saying things
like "Minimize navigational difficulties"

Another way to handle this is to use these terms as part of the explanation
for the goal of groups of statements. As some will remember, I'm a big fan
of standards that explain the high level goal first and then list the
normative requirements. There are three benefits:

1. Readers know why the requirements are important.
2. If technology changes, it's easier to sort out when the specific
requirement is no longer helpful in meeting the goal
3. It makes it clear that the requirements may be a base constraint, but
not sufficient without good design support to actually meet the goal.

Example (very rough, but I hope it communicates the idea)

"In order to ensure that people with disabilities can discover how a
product works:
a. Access features must be documented
b. Any documentation must be in an accessible format
c. Another specific requirement
d. And another"


Having said all that, I think that we could use these concepts as part of
the introductions, but they are essentially usability concepts (not that I
object. just that this may get us back into the area that Haijme was
concerned about).

Here's how they map:

Orientation: discovering what the product does and how it works
In: Documentation, help and support services and Support tools. Also
requirements for tactile keys, etc.

Operation: manipulating the product's controls
In: all sections on input controls

Perception: receiving content and status information
In: all sections on output and displays

Comprehension: integrating and using the information
In: all sections on cognitive and presentation of information

Navigation: finding the proper path to the intended function
(hardest - most "tipped" in the direction of usability)
In: interaction gudelines



As I look at the list of requirements we're trying to organize, this leaves
out a number of important requirements, which are mostly falling in the
group of requirements on Support for Personal AT - all the API-level
interface (not user interface) requirements. And the opening sections on
"modes" and "non-interference"





At 11:09 AM 1/31/2007, Jim Tobias wrote:

>This is very interesting.
>
>I have been looking at another dimension of categorizing accessibility
>standards, and
>obviously usability factors in exactly as you describe.
>
>Here's what I have so far, based on looking at the existing 255 and 508
>standards:
>
>Orientation: discovering what the product does and how it works
>Navigation: finding the proper path to the intended function
>Operation: manipulating the product's controls
>Perception: receiving content and status information
>Comprehension: integrating and using the information
>
>But something tells me that somewhere, someone more authoritative has
>already done
>this. Whitney (and anyone else), are you aware of a "Standard work" on the
>subject
>of categorizing the specific parts of using a product to accomplish a
>function?
>
>***
>Jim Tobias
>Inclusive Technologies
>+1.732.441.0831 v/tty
>+1.908.907.2387 mobile
>skype jimtobias
>
>-----Original Message-----
>From: Whitney Quesenbery [mailto: = EMAIL ADDRESS REMOVED = ]
>Sent: Wednesday, January 31, 2007 10:40 AM
>To: TEITAC General Interface Accessibility Subcommittee
>Subject: Re: [teitac-general] about the word usable
>
>Hajime,
>
>Thank you for the explanation - I completely agree with you: usability and
>accessibility are related, but different.
>
>A slight digression from the topic of structure, but just to follow up on
>the relationship:
>
>In thinking about cognitive disabilities, the line between "usability for
>all" and "access for people with specific disabilities" becomes quite
>blurry. In the voting system standards (VVSG) for example, we created a
>group of requirements around clear language, perception and understandable
>navigation -- but put them in the general usability section. We did this
>because they applied to all voters, not just those with cognitive
>disabilities. These requirements are very difficult to draft in a testable
>manner, however. It's easier when the standard is for a specific type of
>product, of course.
>
>Whitney
>
>
>
>At 10:24 AM 1/31/2007, Yamada@TOYO-UNIV wrote:
>
> >Whitney,
> >
> >For example, a website which only contains texts is "accessible" by
> >everyone. However, if the structure of the website is not the one ordinary
> >people expect, or if the texts include a lot of jargons that are difficult
> >to understand by ordinary people, we feel the website is not "usable" or
> >"easy to use."
> >
> >In Japan, ordinary people use the word "bike" to express the motored
> >two-wheel vehicle (Honda, Yamaha and Kawasaki's.) But the government
> >officials use "light weight motored vehicle" instead of "bike," because
> >"light weight motored vehicle" is the word used in the related legislation.
> >Therefore, many people face difficulty in getting information from
> >governmental website when they want to know how to register "bike." In this
> >case, the website itself is "accessible" but not "usable."
> >
> >I found the word "usable" in your proposal. Thus I made the comment. But
>now
> >I know you changed the word in your proposal. Thank you for the
> >modification.
> >
> >Hajime Yamada
> >
> >
> >

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University