1 Posted by Faruk Ates on 21 July 2005 | Permalink

Ooh, that's a nice little overview. Thanks for the test -- I'll be sure to include this info in an upcoming Javascript application of mine. :-)

2 Posted by Doekman on 21 July 2005 | Permalink

I don't think event-pairing is always necessary (although the onmouseover/onfocus is pretty neat). For example, the double-click. It seems to me this function can also be supplied via a context-menu. And the onmousedown, -move and -up used for drag-n-drop? Use a copy/paste method. Mouse and keyboard functionality doesn't always have to map one-on-one.

3 Posted by Erik Arvidsson on 22 July 2005 | Permalink

I would say your conclusions are incorrect. I don't agree with your conclusions taht IE and Mozilla are almost correct. I would say "Yes" here because the behave the way focus is supposed to work

"Explorer and Mozilla: When you click on a link that does not have the focus, the blur event of the focused link fires."

This is the correct behavior. When an element that has focus loses focus it should dispatch a blur event.

Doing a mousedown on a focusable element causes it to become focused. When a focusable element that does not have focus recieves focus it should dispatch a focus event.

4 Posted by ppk on 22 July 2005 | Permalink

Erik,

As I said in the paragraph right above the table, this table judges the events on their ability to perfectly emulate the mouse events. focus doesn't perfectly emulate mouseover, therefore it has an Almost.

5 Posted by James Edwards on 22 July 2005 | Permalink

"this table judges the events on their ability to perfectly emulate the mouse events"

And that's why the data is not very useful as it is - the notion of event pairing is itself misplaced. The WCAG 1.0 guidelines talk about it, but they're wrong in every important respect. (Mind you WCAG 2.0 doesn't exactly help - it gives an example of "onactivate" - an event that doesn't even exists, except in IE where it means something else completely)

I think it would be more useful to test which action fires which events, and in which order, and put that together into a comparitive table of behaviors, from which we could then find consistent patterns, rather than trying to judge them by whether they meet an arbitrary criterion.

6 Posted by ppk on 22 July 2005 | Permalink

I don't find the criterion arbitrary, but I certainly see your point. The only thing is: I feel that if we do tests like the ones you describe we'll probably end up pretty close to my event pairs.

Only the click event fires for non-mouse users, so if you want to make your mouseovers accessible you'll have to add non-mouse events to the same element. Focus is a rather obvious choice, whichever test method you prefer.

So feel free to do the tests, they're bound to be interesting, but I think they'll lead to the same conclusions as my tests did.

BTW: there are some general event tests available through the Event compatibility tables.

7 Posted by James Edwards on 22 July 2005 | Permalink

Yeah arbitrary was the wrong word - I just meant to say that the criterion is not a useful one - it's a benchmark based on flawed reasoning.

Thinking in terms of event pairs is a misnomer, because the parallels are not there - keyboard events are very different things. Making a script keyboard accessible is not something you can patch on by looking for a paired-event, it's something that has to be considered from the start.

Now it's true that some pairs do inevitably come to mind - such as the pairing with mouseover and focus - but still I don't believe that's really a pair, per se, it's just making an effect work irrespective of input mode.

Nevertheless, I'm not dismissing what you're saying at all, I only wish that you could "show us your workings" as they used to say - the data that informed your judgements, rather than just the judgements.

[btw - I do have some test data from screenreader event handling coming soon - I think you'll be surprised, and disappointed, by the results...]

8 Posted by ppk on 22 July 2005 | Permalink

"I don't believe that's really a pair, per se, it's just making an effect work irrespective of input mode."

True, up to a point. Parallels may not be there, but people will search for them nonetheless, since they've got this script that works with mouse event handlers and they want to make it accessible.

The mouseover/focus and mouseout/blur pairs are useful enough as a first approximation of making these scripts accessible. And let's face it: using focus/blur, too, is better than just using mouseover/out. It may not be good enough, but it's a start.

"Show us your workings": I did the tests on the test pages and decided which non-mouse event was most like the mouse event. That's all. It's not high science, but we have to start somewhere.

That's all I really want: starting somewhere, and see what happens next.

9 Posted by James Edwards on 24 July 2005 | Permalink

"True, up to a point. Parallels may not be there, but people will search for them nonetheless,"

Yes they will, and that's why it's crucial not to mislead them - if someone came looking for advice on the best way to use font tags, you would encourage them not to use font tags at all; not to think in terms of visual markup. The parallel here is just the same.

"using focus/blur, too, is better than just using mouseover/out. It may not be good enough, but it's a start."

In this case it is good enough - it's a near-perfect pairing, but focus/blur and mouseover/mouseout are the only ones you'll find - none of the other "pairs" are anything like each other.

My beef here is that you're misleading people - one could be forgiven, for example, for looking at your examples and trying to "fix" the browsers that don't conform to your definitions so that they do - for example, hack all browsers except Safari to produce a consistent model of mousedown-focus, when in fact Safari is getting it wrong and everyone else is right.

I don't wish to critisize just for the sake of it - I'm delighted that a scripter of your calibre and renown is finally becoming interested in accessibility - but if you want to get started in that direction, I wish you'd step back from the desire to make value judgements and just present information.

10 Posted by ppk on 25 July 2005 | Permalink

If you look at how I present the conclusions of my tests, which are repeated right here on this page, you'll see that the mouseover/focus and mouseout/blur are the only pairs I recommend.

So I'm not misleading anyone: I warn people that it's hard to find other pairs.

Please don't accuse me of things I haven't done.

11 Posted by James Edwards on 25 July 2005 | Permalink

Sorry man, I never meant to sound accusational, but I do believe it's somewhat misleading to encourage people to look for pairs at all.

12 Posted by ppk on 26 July 2005 | Permalink

Hm, yes, there you may have a point. The quick success of mouseover/focus and mouseout/blur may encourage people to search for other pairs.

I still don't think the search in itself is bad, and since we likely won't find any other simple pairs, the danger will probably remain academic.

But let's critically review any other pairs we might find (for that matter, let's critically review the two pairs we already found, too).