Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: Focus and Keyboard Navigation

  • Subject: Re: Focus and Keyboard Navigation
  • From: Roy Schestowitz <newsgroups@schestowitz.com>
  • Date: Sun, 31 Jul 2005 08:15:57 +0100
  • Newsgroups: comp.infosystems.www.authoring.html
  • Organization: schestowitz.com / Manchester University
  • References: <zdAGe.28503$mC.7526@okepread07> <dceqmq$2c86$1@godfrey.mcc.ac.uk> <42ec2be4$0$11950$5a62ac22@per-qv1-newsreader-01.iinet.net.au> <dchq1n$2g9c$1@godfrey.mcc.ac.uk> <42ec6ffc$0$11945$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
  • Reply-to: newsgroups@schestowitz.com
  • User-agent: KNode/0.7.2
RobG wrote:

> Roy Schestowitz wrote:
>> RobG wrote:
>>>Roy Schestowitz wrote:
> [...]
>>>Using 'onchange' with select elements has serious usability issues
>>>with keyboard navigation in IE, particularly if the options cause URLs
>>>to be followed.
>>>Try the following by tabbing to the select, then using the down arrow
>>><select onchange="alert(this[this.selectedIndex].text);">
>>>  <option>Option 1</option>
>>>  <option>Option 2</option>
>>>  <option>Option 3</option>
>>>In IE the alert is fired every time the down arrow is pressed. If each
>>>option is a link, then users will never get beyond the first step
>>>downward before being whisked away to the new URL.
>> I never actually had it tested to account for keyboard behaviour. I can
>> see your point and I wonder how other browsers handle it.
>> With older versions of Netscape, the selection and request to move to a
>> new URL was not obeyed IIRC. I used to remember some more issues with the
>> implementation above. That's why I added a JS-free version wherever I had
>> such a menu placed.
>> Roy
> According to the HTML specification, onchange should fire if the
> control has changed when it looses focus.  In that respect, Mozilla et
> al do it by the book for select elements.
> On the other hand, Mozilla will fire an onchange for a radio button
> the moment it is clicked (effectively making it an onclick event) and
> doesn't wait for the loss of focus.  IE waits for the button to lose
> focus, which has the unfortunate side-effect that when you click one,
> nothing happens.  If you click another, the onchange from the previous
> one fires.
> There are a number of such gotchas - but that's just part of the fun
> of web development!

I wouldn't label it all "fun". It makes Web development more laborious. At
some stage I gave up on testing pages under different browsers and just
ensured that new pages validated. If the browser cannot dipslay valid pages
properly, the browser should be blamed. Alternatively, the formal
specifications should take the blame. For example, a user who cannot use
the mouse might suffer from focus-related decisions. Then again, Windows
has a poor notion of focus (only click window or widget to focus) so not
wonder IE fails.


Roy S. Schestowitz

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index