Re: [XHTML Access] must "activate" be boolean?

Greetings, I want to be sure I understand what is being asked for here. My 
interpretation of the access spec is as follows:

<access key="k" activate="no" targetid="xx" />
would result in the element with an id="xx" receiving focus and 
consequently dispatching a DOMFocusIn event, and that is all.

<access key="k" activate="yes" targetid="xx" />
would result in the element with an id="xx" receiving focus and 
consequently dispatching a DOMFocusIn event.
the element than now has focus is activated and as a consequence a 
DOMActivate is dispatched. 

So. . . , Gregory's original request

  "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..."

only appears to ask for an optional inspection step to be introduced. . . 
<access key="k" activate="yes" targetid="xx" />
would result in the element with an id="xx" receiving focus and 
consequently dispatching a DOMFocusIn event.
"inspect the focus element"
the element than now has focus is activated and as a consequence a 
DOMActivate is dispatched. 

but I suspect that upon inspection the user should be allowed to cancel 
the activation.

So, a couple of questions:
 1) is my suspicion correct, is it requested that upon inspection the user 
should be allowed to cancel the activation?

 2) XHTML Access Module does not say anything about what the context info 
would be in the DOMActivate, e.g. in DOM 2 would the context info be 1 or 
2? There seem to be some changes taking place between DOM 2 and 3 Events 
in the context information associated with DOMActivate. 

Regards, Roland
FBCS, CITP
IBM Software Group, Strategy, Software Standards




Shane McCarron <shane@aptest.com> 
Sent by: public-xhtml2-request@w3.org
14/04/2008 19:21

To
"Gregory J. Rosmaita" <oedipus@hicom.net>
cc
public-xhtml2@w3.org, w3c-wai-ua@w3.org, wai-xtech@w3.org
Subject
Re: [XHTML Access] must "activate" be boolean?







I am trying to leave on holiday, and I am sure that others can 
contribute to this discussion.  My quick answer to this complex question 
is that "activate" should be boolean because it maps directly to the 
underlying DOM Event.  For a richer event mechanism, you need to leave 
activate to its default (which is "no") and define custom event handlers 
either for the access element or, more likely, for its target(s).  We 
debated permitting the richer event model in the Access module itself 
via a "deliver" attribute or some such, but in the end determined that 
we would just be duplicating functionality from XML Events.  Poorly.

Gregory J. Rosmaita wrote:
> 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
> -----------------------------------------------------------
>
> 

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com










Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU