Re: penetrating analysis of accesskey alternates

Hi John,

I understand those issues you raise. In the quick write up  I tried  
to address all of those issues as well. I think this goes beyond  
simply the role attribute. Though one might stretch role to serve all  
of these purposes it would only confuse the situation. I think the  
current use of targetrole and targetid need to be supplemented by  
even leaving target off (a null target). Similarly, my suggestion of  
using QNames  for key bindings and cascading the key bindings  
addresses your other concern that users should be in control.

I think many of the previous analyses of these issues has not been  
creative enough in solving these problems. In many ways I was simply  
applying many of the standard techniques found in the W3C and object  
oriented programming communities. For example Apple's object-oriented  
environment makes use of this target/action approach, even allowing  
the specification of a null target to imply the first responder to  
the keyboard event relative to the current focus.

The other innovation simply involves using QNames to abstract from  
the various operating environments that users operate within. One way  
to think of this abstraction as making use of naming the role of a  
keystroke in a user's operating environment. That combined with   
applying a cascade approach means that users remain in control of  
their key bindings while authors can still provide rich applications  
with complete keyboard interaction.

Perhaps I should write this proposal up in a more formal manner. It  
could use its own wiki page for solutions rather than being buried in  
the page about dropping the accesskey attribute (which it bears  
little relation to anymore).

Take care,
Rob

On Aug 27, 2007, at 4:31 PM, John Foliot wrote:

> Robert Burns wrote:
>> Markup
>> is simply a way to encode data. So encoding key bindings through
>> markup is not a problem.
>>
>> I've been thinking this exact same approach could be applied as an
>> automatic solution for document that embed video or audio (time-
>> based) media. When encountering a document with video or audio, the
>> UA would automatically add accesskey elements to the DOM for: 1)  
>> play/
>> pause; 2) scan forward; 3) scan backward; 4) track forward 5) track
>> backward 6) volume up; 7) volume down; 8) focus next embedded; and 9)
>> focus previous embedded. By doing so anyone encountering embedded
>> content like this would automatically be able to control the time-
>> based media on the page. Each is simply a DOM API call on the
>> targeted element (either an embedded content element such as OBJECT
>> for (1) - (7) or the root element for document for (8) & (9) )
>
> Rob,
>
> The major issue with author declared keybindings is that there is no
> standardization, thus it increases the need for "discoverability"  
> by the
> various user-agents.  As well, across the board, various user- 
> agents have
> already "reserved" different keys for various reasons: screen reading
> technologies being the most intensive consumers of keybindings (as  
> "mouse"
> does not work).  Also, not all user-agents have a full QWERTY keyboard
> (cellphones?), or the keyboard is mapped to "foreign" languages/ 
> character
> sets - what then?
>
> The XHTL2 concept of @role, coupled with either a 'standard'  
> reference of
> common roles (including your suggestions of play/pause, forward,  
> backward,
> etc.), or custom roles (XHTML2 suggested RDF to define these custom  
> roles)
> allows (allowed?) content authors to encode intent, but leaves  
> individual
> user-agents the ability to bind to keys that work within *their*  
> environment
> (or that of the user).  This puts the decision in the hands of the  
> end user,
> rather than the author - a place I suggest is much more user- 
> friendly.  As
> well, because of the envisioned commonality of major inter-page  
> nodes (be it
> id'd regions [navigation, content, footer, etc.] or widget controls  
> such as
> you suggested), the end user can map once and re-use on all pages, as
> opposed to learning a particular authors "list".  Already, UAs like  
> Opera
> allow this type of customization.
>
> Thus, I suggest that allowing authors to specify an actual key is
> counter-productive: declare the intent but leave the binding to the  
> user.
> (See also: http://www.wats.ca/show.php?contentid=47#)
>
> JF
>

Received on Monday, 27 August 2007 21:44:43 UTC