Components rendered the same

Christophe, Gian, Yvette, and I took an action [1] to make a proposal regarding the removed success criterion "controls that look or sound the same should be designed to act the same" in one of last week's polls [2]. We still feel strongly that this should exist as a success criterion. We propose the following wording for a success criterion in Guideline 3.2:

"Within a set of delivery units, components that are rendered the same have the same function."

We prefer this at level 2 but have discussed the possibility that it may end up at level 3.

Some reasoning for this (extracted from comments from Yvette and Christophe):

We already have an SC that says that items that have similar functionality should look the same. I think the reverse should also be true: if it walks like a duck and talks like a duck, it had better be a duck. 

All the examples against this  have to do with the fact that the functionality need not be *exactly* the same. For example: a "next page" link on page 1 goes to page 2, where a "next page" link on page 3 goes to page 4. Other example: a STOP sign on one page may mean the music will stop, while on another page it might mean that the automatic scrolling of the text will stop. However, this is not a reason not to have such an SC. In this example, if you define the functional outcome as 'the next page' (current page +1) instead of wiring it to a specific number then it is OK to say "same functionality". It's the same with "Send mail" in a web mail application: it always does the same thing in the sense that it sends the mail to the addressee(s); it's function is not defined as "Send mail to Yvette".

We believe this addresses the objections of which we are aware.


--- Signature ---

Michael Cooper
Accessibility Product Manager, Watchfire
1 Hines Rd Suite 200, Kanata, ON  K2K 3C7  Canada
Tel: +1 (613) 599-3888 x4019
Fax: +1 (613) 599-4661

Received on Tuesday, 30 August 2005 21:50:02 UTC