Re: penetrating analysis of accesskey alternates

HI Chris,

If you take a look at the page Gregory cited, you'll see my  
suggestions attempt to address the very concerns you raise[1]. Markup  
is simply a way to encode data. So encoding key bindings through  
markup is not a problem. Any desktop application needs to encode key  
bindings in some way (may are now using XML to do so). So the  
suggestion is to add several things to the XHTML2 accesskey element.  
One of those includes an action attribute the specifies the DOM  
action on the targeted DOM element. It also provides for a flexible  
way to specify and select targeted DOM elements. I think most of the  
issues you raised here are addressed in the proposal. If you have a  
chance to read it and think other things are missing, I'd love to  
hear about them.

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) )

Take care,
Rob

[1]: <http://esw.w3.org/topic/HTML/DroppedAttributeAccesskey#head-
22efce57efc348efacfea2261f305615a5882d12>


On Aug 27, 2007, at 3:04 PM, Chris Blouch wrote:

> It seems like any kind of keyboard mapping implemented via markup  
> is going to fall short. In the web 1.0 world of static pages where  
> clicks followed links to reload pages, markup-based keyboard  
> controls would not be an issue. Today many sites update content on  
> the page by ajaxing in new stuff and/or manipulating the DOM to  
> create/modify/destroy nodes at will. These actions are primarily  
> implemented via client side Javascript so any solution which plays  
> well is going to need to map keyboard controls to JS methods/ 
> functions or resign themselves to web 1.0 applications. In  
> particular the ideal solution will bind a keyboard combination to a  
> DOM node to a function/method. In this way hitting that keyboard  
> combination will only activate the JS function/method when focus is  
> on that particular DOM node (contextual behaviors). Maybe I'm  
> missing something but I can't imagine an HTML construct which would  
> allow me to annotate a DOM node (maybe CSS selectors?) not to  
> mention a JS function or method. Even if we could the function or  
> DOM node might not even exist to be bound until later after the  
> page loads - putting it beyond the scope of the HTML parser to  
> instrument. This branch of standards definition feels like it is  
> constrained to the point that it may not be all that useful. The  
> solution set feels more like API than markup.
>
> CB
>
> oedipus@hicom.net wrote:
>> aloha, all!
>>
>> it would be well worth everyone in the WAI's time to review robert  
>> burns' analysis of the objectives in improving accesskey (based on  
>> the pro and con argumets listed under the rationale for  
>> deprecating accesskey)
>>
>> the accesskey deprecation page in HTML WG wiki space is located at:
>>
>> http://esw.w3.org/topic/HTML/DroppedAttributeAccesskey
>>
>> RBurns' contributions can be directly accessed using the following  
>> long,
>> probably line-wrapping archive-breaking URI below:
>>
>> <http://esw.w3.org/topic/HTML/DroppedAttributeAccesskey#head-
>> 22efce57efc348efacfea2261f305615a5882d12>
>>
>> or, if you are able to navigate by headers, it appears on the wiki  
>> page under the level 2 heading "Considering solutions other than  
>> removing the attribute"
>>
>> it is an excellent review of the pros and cons and suggested  
>> improvements, and highly recommended reading for anyone interested  
>> in the future and/or improvement of the accesskey as defined in  
>> HTML 4.01
>>
>> gregory.
>>    ----------------------------------------------------------
>>    The best way to become a successful writer is to read good     
>> writing, remember it, and then forget where you remember    it  
>> from.                                    -- Gene Fowler
>>    ----------------------------------------------------------
>>    Gregory J. Rosmaita: oedipus@hicom.net
>>    Camera Obscura: http://www.hicom.net/~oedipus/
>>    Oedipus' Online Complex: http://my.opera.com/oedipus/
>>    ----------------------------------------------------------
>>
>>
>>

Received on Monday, 27 August 2007 20:23:48 UTC