RE: penetrating analysis of accesskey alternates

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:32:09 UTC