W3C home > Mailing lists > Public > wai-xtech@w3.org > April 2008

[XHTML Access] must "activate" be boolean?

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Mon, 14 Apr 2008 18:03:16 +0100
To: public-xhtml2@w3.org, w3c-wai-ua@w3.org, wai-xtech@w3.org
Message-Id: <20080414170027.M81596@hicom.net>

disclaimer: i fully realize that simply because the XHTML Access 
Module is so named, it isn't a document that is intended for 
accessibility per se, but exists to define a standardized mechanism 
for anyone to access objects and elements from the keyboard, whatever
form that keyboard might take...

still, i have a question on the most recent working draft, given the 
second paragraph of Section 3.1.2.

<quote 
cite="http://www.w3.org/MarkUp/2008/WD-xhtml-access-20080418/#sec_3.1.2.">

Triggering an access key defined in an access element changes focus to 
the next element in navigation order from the current focus that has one 
of the the referenced role or id values. Note that it is possible to 
deliver alternate events via [XMLEVENTS]. It is also possible to have the 
target element activated through the use of the activate attribute. 
Finally, it is possible to associate additional event handlers with 
target which might then perform additional actions once focus is changed.

</quote>

must activate be boolean?  or, rather, can it logically be boolean, given
that alternate events may be available through the defined "key", and it 
is usually the user who knows which event is most suitable for that 
user's needs...

which brings us to the the scenario where a user who wishes to move 
focus to an element for which an access element has been defined, but 
who needs to delay the event (if activate="yes") in order to inspect 
the object with focus for whatever options it might contain...  is the 
assumption that this be where an assistive technology kicks in by 
responding to an access command by moving focus and then -- through the 
assistive technology's UI -- provide an exposition of possible 
actions/options, before the user decides to trigger the event?  there 
is a large population served by accessibility features that do NOT use 
nor need a dedicated assistive technology, so is it fair to place the 
onus for

activate="inspect"

on assistive technology, when, given the possibility of defining multiple
events for a single element, such a functionality should be built into 
the access module itself?  it is similar to the trigger concept, endowing 
activate with an additional safety mechanism -- the ability to half-cock 
the trigger before deciding whether or not to fire, at which target to 
fire (in the case of multiple targets/events, or whether to uncock the 
trigger...

gregory.
-----------------------------------------------------------
IMPARTIAL, adj.  Unable to perceive any promise of personal
advantage from espousing either side of a controversy or 
adopting either of two conflicting opinions.
                  -- Ambrose Bierce, The Devil's Dictionary
-----------------------------------------------------------
    Gregory J. Rosmaita: oedipus@hicom.net
         Camera Obscura: http://www.hicom.net/~oedipus/
Oedipus' Online Complex: http://my.opera.com/oedipus
-----------------------------------------------------------
Received on Monday, 14 April 2008 17:03:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:45 GMT