Re: activating behaviours

On Wed, 11 Jul 2012 12:24:31 +0200, Ramón Corominas
<listas@ramoncorominas.com> wrote:

> Of course, I understand your concerns, but...
>
> What should I do NOW?

I think now you should add tabindex, but not keyboard handlers, to buttons.

(More generally, you should do the minimum necessary to make stuff work  
well - and no less ;) )

> Because NOT ALL browsers trigger the "onclick" event when the space bar  
> is pressed.

Right. (That is not, a priori, a problem).

> Not all browsers act the same

Exactly. In particular, not all browsers use space to trigger a button.

> nor trigger onclick events unless you include an event handler for it
> (even if their default behaviour with radio-buttons is that).

If there is *no* keyboard way to trigger a click, then you *do* need to do
something. If it is just that it doesn't always use the space bar, there
is no problem. Leave the user to choose the browser and UI they are happy
with.

> And, indeed, I'm not sure that browsers should really trigger an onclick  
> event when the space bar is pressed, because the space bar IS NOT a  
> mouse click.

There should be *a* way to trigger a "click" event from the keyboard. I
believe there is - this is the reason that we removed the "activate" event
   from DOM - although it is called "click" it can be triggered by more or
less any UI - touch screens, voice control, keyboard, mouse, TV remote, ...

Whether it is space bar or some other key or some other mechanism entirely
is something the browser UI should determine, not the page.

> IMHO, default behaviours like triggering "clicks" through "taps" or  
> "space/enter keys" is just a trick to make things work in situations  
> where the author didn't take the time to include specific events, but I  
> am not sure that it is "the right way" to proceed.

No, it is the other way around. The author defining a complete UI to the
level of which key does what is just a trick for cases where the browser
didn't make it possible to activate the necessary controls. The right way
to proceed is for the author to define the application, give it the
controls necessary to use it, and make sure those can be activated by
browsers - whatever kind of browser the user has.

There is a pyramid of needs here. The user needs to interact with their
browser all the time, but even if you are making facebook the user
probably doesn't interact with your site all the time they are on the web.
So the author should defer to the browser for details of how to activate
elements in the page.

The only reason to actively interfere is when the browser actually doesn't
allow the user to do something *at all*.

> Moreover, should I also forget about arrow keys, since they can be used  
> to scroll up and down? Should I forget sliders with left/right arrow,  
> since they could be needed for horizontal scrolling? Should I forget to  
> provide left/right interaction through the tabs in a tab panel? no  
> up/down in a tree view? Not left/right to open/close a tree node? Should  
> I forget custom widgets?

No, but you should forget adding custom control interaction unless it is
really necessary. Where you do add it, you should look for methods that
interfere as little as possible with the existing UI.

Almost all accesskey implementations had to be fixed (and have been)
because the first implementations caused as much harm as good. On top of
that, the problems caused authors to avoid, and then forget, using
accesskeys. Which are worth another look in the context of modern browsers
as an alternative to javascript key handlers.

> Sorry, but I think you are not being realistic about current browser  
> implementations. It sounds to me like saying "we must not provide a  
> 'skip to content' link because browsers *should* do it", or "we must  
> never include buttons to increase/decrease text size nor changing  
> contrast, because browsers should be able to do it".

Not at all. By all means add functionality, on the off-chance that the
user doesn't know how to use it or the browser doesn't have it (in your
first example there are only a tiny handful of browsers that offer this,
in the second I can't think of any that don't).

Where you are *directly interfering* with the user's UI, you should be far
more careful about whether you are actually helping, or causing problems.
When you add keyboard handlers in javascript, you are very likely to
interfere with the UI of people who control their browser in whole or part
through the keyboard.

I *believe* (without testing - my sorry excuse for a computer can only run
a few browsers and I haven't got test results ready to hand) that if you
add tabindex to things then users can navigate to them with the keyboard,
and make a click happen. The fact that it might be the space bar, or the
enter button, or the OK button, or the 'A' button, or the trigger (e.g. on
a Wiimote), is irrelevant and the author shouldn't be insisting on the
particular method that is used.

Another example of when not to interfere (IMHO):
Most desktop browsers use the tab key to move around all active elements
on a page. Opera and Safari (at least Safari on Mac) have different
defaults, where they use tab only to move between form elements and
various parts of the browser interface. They both provide a mechanism for
the user to choose to do things differently, but most users stick to the
default.

There is no good reason to write a script that traps presses of the tab
key on those browsers and make it behave the way other browsers do - they
both offer multiple ways of getting to other things, which happen to be
different. I assert that it is *harmful* to force a different behaviour of
the tab key on a particular page, just because it isn't the same as the
"normal".

FWIW I also think Opera are stupid for not using the tab key the way other
browsers do, and reassigning their default shortcuts so the smarter set of
options doesn't interfere - but that's a browser choice and when Opera did
briefly try that approach a few years ago it was reverted due to howls of
discontent from a number of their users.

And another example of causing problems:
Touch screens generally don't have a concept of a cursor. So using
mouseover for anything that actually matters will not work. This leaves
authors with several options:
    1. Add a cursor to the page for touch-screen devices.
       IMHO this is a terrible idea in practice. Not least, because it is
immensely complicated
    2. On touch screen devices, intercept the first touch and make it  
trigger
the mouseover behaviour, with the second touch being registered as a real
click.
       I hope it is obvious why I reject this solution out of hand.
    3. Don't rely on mouseover working for the user to intereact with your
content.
       Among other benefits, this is relatively simple.

I'm sure there are people who have figured out some really clever way to
deal with these things. Everyone complains that you can't get the title of
an element if you navigate with the keyboard, but it's a single CSS
statement in browsers that allow element navigation, and adding tabindex
based on querySelectorAll('*[title]') is simple enough otherwise. But that
interferes with the original UI, so should be handled with care.

And another that I randomly ran across just before sending this:
[[[
why does twitter's "compose new tweet" box hijack my command-shift-} key?
And why does firefox allow it to?
]]] https://twitter.com/ger/status/217335132581928960

Cheers

Chaals

> Cheers,
> Ramón.
>
> Chaals wrote:
>
>> The problem is mediocre browser implementation. Trying to solve it in  
>> individual pages is risky. In particular, adding traps for particular  
>> keys to simulate a click is harmful, since
>>  1. It is unnecessary
>>  2. It can interfere with the user's normal interaction
>> But adding tabindex is necessary and doesn't interfere and is therefore  
>> a good idea.
>


-- 
Chaals - standards declaimer

Received on Wednesday, 11 July 2012 11:31:42 UTC