- From: Jim Allan <jimallan@tsbvi.edu>
- Date: Thu, 17 Apr 2008 17:14:49 -0500
- To: "'Roland Merrick'" <roland_merrick@uk.ibm.com>, "'Shane McCarron'" <shane@aptest.com>, "'Gregory J. Rosmaita'" <oedipus@hicom.net>
- Cc: <public-xhtml2@w3.org>, <public-xhtml2-request@w3.org>, <w3c-wai-ua@w3.org>, <wai-xtech@w3.org>
- Message-ID: <030301c8a0d8$77f1e220$67d5a660$@edu>
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
Received on Thursday, 17 April 2008 22:18:32 UTC