key events spec - some issues I'd like to give some attention

Chaals asked if I wanted to help out with DOM3 key events activity, and I said "sure". He says I don't know what I've let myself in for, which is entirely true, but I assume it is about helping out editing some sort of spec and paying a bit of attention to relevant threads on this mailing list.

As I've said yes to this somewhat underspecified task I'll first say a few words about me: I work for Opera Software, where I've been employed part-time for some 8 years or so. During these years in customer service and QA I've mostly been analyzing issues with web sites and -applications, so what I bring to the table is a fairly thorough understanding of the wild and varied practices out there. What I *don't* have is any sort of formal/theoretical background in computer science, so when discussions get highly abstract and jargon-filled it might take me a while to digest them. I don't think I'm good at writing spec prose but I'm prepared to climb that learning curve with some assistance from the *real* programmers and hackers among you :-).

Now, since Chaals asked I've spent a bit of time thinking about the problems I'd like to help addressing.

On a high level, we're working on letting an app specify an association between an input (key event, accesskey etc.), a context (usually element, but also document/window and chrome like scrollbars) and an action (JavaScript function or a default action). Some of the associations also imply a description of the action (link text or title, element title).

The problems I think we ought to try to address include:

* Inconsistent legacy event support among UAs, "DOM0" events are underspecified
* The web is full of inflexible character code-action mappings, causing bad accessibility from keyboards or devices that were not taken into account by the programmers
* Accesskey might be a solution, but does not support multiple consecutive keys (like GMail's "gi" shortcut to load inbox), and need to be specified and implemented so that UAs can map actual existing keys rather than specified ones (this is done in HTML5)
* UAs can not offer alternative activation for most event listeners because they are too generic and lack descriptions for UI. (Say if an app does document.addEventListener('keypress',..) to handle shortcuts - not granular enough to offer any kind of sensible description to show the user and ask "do you want do do x?")
* The thorny UI issue of whether page shortcuts or UA shortcuts take preference. I know many of you will feel this is a UI/implementation issue - which is perfectly true - but it is important for UA accessibility to think about and offer some guidance for these dilemmas. Both configurability and a "cascading" model where more specific shortcuts can take preference over less specific ones are worth exploring.

Then of course we have the issues I think you're already close to solving, like IME/virtual keyboard events, and more specific/granular events for editable content. 

There are probably more issues that fell off the table right now but will surface again.

What I think I'd like to happen..
 
* DOM0 Key Events Spec
* Normative table of virtual key codes for legacy support even on non-Win32 platforms and devices..
* DOM3 Key Events Spec w/IME events and all that
* Shortcut Mode Spec - triggering a mode where the client assigns shortcuts to elements/actions the page indicates should have shortcuts, or any "activatable" element if the page has no such indications. Like Opera's access key mode but more powerful. And with a normative spec.

Now, how do I start editing or helping out here?

One final word: since I work part-time, have small children and sometimes many things going on in life I don't guarantee a "heartbeat" response rate. Since apologies in advance if this will hurt the timeliness of mailing list discussions. I *will* get to things but not always quickly.

-- 
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

Received on Monday, 6 July 2009 11:02:44 UTC