Re: activating behaviours

TL;DR:
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.

The longer version...

On Tue, 10 Jul 2012 22:12:01 +0200, Ramón Corominas  
<listas@ramoncorominas.com> wrote:

> I understand that issues might exist when adding keyboard events if the  
> different OS's or browsers have different default behaviours.

I believe we all agree on that principle.

> However, I wonder how would you expect to manage keyboard interaction
> without attaching keyboard events to the custom controls (unless you
> pretend that developers don't use custom controls at all, which
> obviously will not occur).

Right, developers will add custom controls. That's why ARIA exists :) And  
I think we agree that the need isn't going to go away. So your question  
here is key...

> If you see the radiogroup example in my presentation, space bar is not  
> the only key being considered. Indeed, I've noticed that in some  
> browsers it works directly, even if I don't include an event handler for  
> the space bar.

Right. And that is what should happen in general. Fundamentally, the  
browser *should* recognise a custom control tagged as a native one (let's  
continue with the example of a radio group), and should provide the same  
interaction as it does for a native control.

> But I cannot figure out a way to achieve the final result without  
> programming keyboard events for the arrow keys. In a radio-group only  
> the group itself is focusable, not each individual radio-button.  
> Individual radio-buttons are accesed using the arrow keys. So, how would  
> you manage to control focus without keyboard events?

Let's propose a browser that uses space bar to advance a page - because  
there is no longer an easily-operated "page down" key. (This is not  
hypothetical, it is the case for more or less every macintosh laptop,  
among others). It uses the enter key to activate buttons, a tab key to  
move around form elements, and arrow keys to move between all active  
elements.

What it *should* do is recognise that an image which is part of an  
ARIA-defined radio group should behave the same as a normal radio button.  
The browser should enable access. If I, as a user, expect the space bar to  
let me page through a form, and instead it starts activating buttons, I  
get lost. So the form shouldn't decide to arbitrarily re-map my  
navigation, just because the author thought there was a convention.

Take a further case of a mobile browser for a keypad phone - say one of  
the millions of s60 phones that are in use today (especially across the  
developing world, where more and more of them are appearing in 2nd hand  
stalls) and can run Opera Mobile. It uses numbers and other key sequences  
to control various functions including navigation. Although there is a  
"convention" that mobile sites use numbers for links, through accesskey,  
using javascript to trap key input and force this will break the user  
experience. Unnecessarily.

The bugs here are not in websites, but in browsers. Although some browsers  
use space to activate buttons, not all browsers do - nor should they be  
assumed, let alone forced, to do so. The situation is no longer bad enough  
that you *cannot* make a browser allow keyboard interaction without  
javascript - more or less all browsers enable click events.

Adding tabindex to things that will accept a click is still required in  
many cases, otherwise browsers don't allow the user to get to the thing to  
be clicked. But we are no longer in a world where we should encourage  
authors to add javascript keyboard handlers which specify particular keys  
just to click things. They introduce serious long-term problems, and the  
sooner we can get rid of them the better.

There is a principle here of minimally interfering with the "normal" way  
of doing things. But rather than "enforcing" a "normal way", the idea is  
to assume that there is *a* normal way for a given user. If it works, we  
have nothing to do. If there is a fundamental problem, like "it is  
impossible to focus an element so it can receive a click" then we do  
something - add tabindex. But if there is a way to generate a click, we  
shouldn't be forcing the user to employ some different method because we  
think it is normal.

> I guess that Indie UI will solve this problems in the future, but it  
> will take a long time to reach that point.

No, we don't need to wait for IndieUI to handle clicking. It can be done  
by sensible implementations of ARIA - admittedly ignoring the nonsensical  
restriction that ARIA is only allowed to affect accessibility APIs. That  
restriction is nonsensical in part because it cannot be tested anyway in a  
meaningful way. Consider the following cases:

When Opera had voice control and output was that an accessibility API as  
many Opera developers thought, or is it not allowed to handle ARIA?  
Opera's customisable keyboard setups, or mouse gestures that can be  
defined for more or less any function the browser can perform? I could  
write a browser extension with getUserMedia that makes gesture recognition  
interface so a user with limited movement doesn't have to buy a seperate  
piece of hardware - is that an accessibility API or isn't it allowed to  
hook into ARIA?

-- 
Chaals - standards declaimer

Received on Wednesday, 11 July 2012 09:59:03 UTC