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

These are personal comments, not UAWG consensus. Comments preceded by <jim>

Jim Allan, Co-Chair UAWG

Roland wrote: 
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. 
<jim> ok</jim>

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

<jim> ok</jim>

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. 

<jim> agree</jim>

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? 

<jim> yes, in essence the inspection would be equivalent to activate="no".
the user has the option to activate the control or change focus. </jim>

 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. 

<jim>I don't know enough about DOM to answer this question. Its seems
whatever the context it should be cancelable. 

<quote
cite="http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.html"
> DOMActivate

The activate event occurs when an element is activated, for instance, thru a
mouse click or a keypress. A numerical argument is provided to give an
indication of the type of activation that occurs: 1 for a simple activation
(e.g. a simple click or Enter), 2 for hyperactivation (for instance a double
click or Shift Enter). 

.        Bubbles: Yes

.        Cancelable: Yes

.        Context Info: detail (the numerical value)

</quote>

On reviewing the XHTML Access Module I found the statement "User agents may
provide mechanisms for overriding the setting of the activate attribute. In
such user agents, user-specified settings must take precendence
[precedence]."

The User Agent Accessibility Guidelines 1.0 and 2.0 have checkpoints that
parallel that statement in the Access Module. 

UAAG 1.0 Checkpoint 9.5 (a level 2 requirement)  [1] - "Allow configuration
<http://www.w3.org/TR/2002/REC-UAAG10-20021217/glossary.html#def-configure>
so that moving the content focus
<http://www.w3.org/TR/2002/REC-UAAG10-20021217/glossary.html#def-content-foc
us>  to or from an enabled element
<http://www.w3.org/TR/2002/REC-UAAG10-20021217/glossary.html#def-enabled-ele
ment>  does not automatically activate
<http://www.w3.org/TR/2002/REC-UAAG10-20021217/glossary.html#def-activate>
any explicitly associated event handlers
<http://www.w3.org/TR/2002/REC-UAAG10-20021217/glossary.html#def-event-handl
er>  of any event type."

UAAG 2.0 Success Criteria 3.12.11 (a level 1 requirement)  [2] - "3.12.11 On
Focus: The user has the
<http://www.w3.org/TR/2008/WD-UAAG20-20080312/#def-configure>  option of
ensuring that moving the content focus
<http://www.w3.org/TR/2008/WD-UAAG20-20080312/#def-content-focus>  to or
from an enabled element
<http://www.w3.org/TR/2008/WD-UAAG20-20080312/#def-enabled-element>  does
not cause the user agent to take any further action."

However, there was only 1 conforming user agent during implementation
testing for UAAG 1.0 in 2002 (it is no longer available).  I just tested 3
Windows browsers using the UA test suites for onfocus events [3] - all
failed. Not the same as testing the 'activate="yes"' but as close as I could
get. None of the 3, that I know of,  currently have a mechanism to not fire
onfocus events. 

This is an ongoing implementation/conformance issue. </jim>

 

1.
http://www.w3.org/TR/2002/REC-UAAG10-20021217/guidelines.html#tech-configure
-no-handlers

2.      http://www.w3.org/TR/2008/WD-UAAG20-20080312/#principle-perceivable 

3.      http://www.w3.org/WAI/UA/TS/html401/cp0905/0905-ONFOCUS-ONBLUR.html