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.htmlReceived on Thursday, 17 April 2008 22:18:32 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:38 UTC