Re: FW: Browser 'back' is_a Undo (fwd)

Except that in the area of cognitive disabilities, having multiple versions
of what is allegedly the same function, that does not behave in a predictable
way, is probably a reasonably serious problem.

Also, we have three levels of priority. P1 is clearly basic access. P2 is
useful access, which is stepping into the area of usability. P3, as I
understand it, is essentially useability. And that is becuase there isn't a
hard dividing line. I think the idea of having P3 requirements is a good one,
in part becuase the usability stuff is important, and in part becuase it
shows developers where to aim for.

Charles McCN


On Thu, 10 Feb 2000, Gregg Vanderheiden wrote:

  
  
  -----Original Message-----
  From: 	Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
  Sent:	Thursday, February 10, 2000 4:03 PM
  To:	'jn@tommy.demon.co.uk'; 'wai@tommy.demon.co.uk'
  Subject:	RE: Browser 'back' is_a Undo (fwd)
  
  Hi John,
  
  Hmmmmm    it is a toss up whether these are good web design issues or
  Disability Access Issues.
  We try to limit the guidelines to just ACCESS issues.
  I'll float them to the list though (unless WAI@tommy does that already)
  Gregg
  
  -----Original Message-----
  From:	John Nissen [mailto:jn@tommy.demon.co.uk]
  Sent:	Thursday, February 10, 2000 11:16 AM
  To:	wai@tommy.demon.co.uk
  Subject:	Re: Browser 'back' is_a Undo (fwd)
  
  Hello WAI people,
  I have two questions: one concerning the web content guidelines, and one
  concerning user agent design.
  1.	Web content guidelines
  
  The visitor is often confused when the web designer adds a button labelled
  "back" on the page.  The user has no idea whether this has the same effect
  as the "back" button on the browser, and, if not, what the difference is.
  As a general principle, I suggest:
  "Leave the browser to do the functions it can do, and have the web
  applications only to do the functions which the browser cannot do."
  Should this principle be embodded in the content guidelines?
  
  2.	User agent design
  
  Even little efforts by the web designer to "help" the user in navigation can
  be problematical.  For example I have seen a "top" button at the bottom of a
  page, designed to make it easier for the user to get to the top of the page.
  After pressing "top", the next press of the browser's "back" button may take
  you to the bottom of the page, but I believe that with most browsers it will
  not take you back to the previous page you visited, as you probably wanted
  it to.
  What _should_ the browser do in this case?
  As a general rule, should the browser put links _within_ a page on the
  return stack or not?
  Do the user agent guidelines have anything to say on this?
  Cheers,
  John
  --
  Forwarded message follows:
  >Date: Mon, 07 Feb 2000 13:56:32 GMT
  >From:	jn@tommy.demon.co.uk (John Nissen)
  >Reply-To: jn@tommy.demon.co.uk
  >Message-Id: <63463@tommy.demon.co.uk>
  >To:	uaccess-l@trace.wisc.edu
  >Cc:	chi-web@acm.org, jn@tommy.demon.co.uk
  Subject:	Re: Browser 'back' is_a Undo
  
  >In message <Version.32.20000206120937.01148680@pop.iamdigex.net>
  >Al Gilman writes:
  >
  >>>Forwarded message follows:
  >>>
  >>>Date:         Fri, 4 Feb 2000 10:57:55 +0100
  >>>Reply-To: Pascal MAGNENAT <pascal.magnenat@INTERACTIONS.CH>
  >>>Sender: "ACM SIGCHI WWW Human Factors (Open Discussion)"
  <CHI-WEB@acm.org>
  >>>From:	Pascal MAGNENAT <pascal.magnenat@INTERACTIONS.CH>
  >>>Subject:	61% of users could not buy train tickets on the Swiss Federal
  >>>              Railways site
  >>>To:	CHI-WEB@acm.org
  >>>
  >>>
  >>>Possible origins of poor usability:
  >>>
  >>>- unpredictable effect of the browser "back" button (many users tried to
  >>>delete an item thrown in the trolley [aka shopping cart] by this means)
  >
  >>This is an absolutely stunning clue.
  >>
  >>In all the fighting about whether 'Back' should be a scripted button on
  the
  >>page or a browser function, I had not previously heard this.
  >>
  >>To make hypermedia browsing accessible to the iOpener customer base, we
  >>have to understand that "undo link traversal" is a special case of "undo"
  >>in the user's total experience.  We need to make sure that all these
  >>flavors of "undo" blend smoothly so that the user is not surprised by what
  >>they do.
  >>
  >>It's not just clicks that we need to sort out over the subprocess or layer
  >>stack to see who gets to handle them.  It's 'undos' too.  And the user
  >>doesn't want to know there is a difference.
  >>
  >>Al
  >
  >In this case the confusion in the user's mental model is over whether
  >"back" means "back in time" (i.e. undo) or "back in space" (i.e. return
  >to where you were).  "Undo link traversal" is clearly "back in space"
  >or simply "return".  The term "undo" is associated with a "do" or
  >"input" action, rather than a "go" or "navigation" action.
  >
  >This type of confusion arises when the web designer adds a button
  >labelled "back" on the page.  The user has no idea whether this has
  >the same effect as the "back" button on the browser, and, if not,
  >what the difference is.
  >
  >If the user is to be allowed to undo as well as to return,
  >there should be a specific "undo" button on the page.
  >
  >As a general principle, I suggest:
  >
  >"Leave the browser to do the functions it can do, and have the web
  >applications only to do the functions which the browser cannot do."
  [rest cut]
  --
  Access the word, access the world       Tel/fax +44 20 8742 3170/8715
  John Nissen                             Email to jn@tommy.demon.co.uk
  Cloudworld Ltd., Chiswick, London, UK   http://www.tommy.demon.co.uk
  

--
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
21 Mitchell Street, Footscray, VIC 3011,  Australia

Received on Thursday, 10 February 2000 19:29:16 UTC