- From: gregory j. rosmaita <oedipus@hicom.net>
- Date: Wed, 23 May 2001 05:03:28 -0400
- To: <w3c-wai-ua@w3.org>
meta note 1: the "onfocus" event handler is defined in the HTML 4.01 Technical Recommendation at: <http://www.w3.org/TR/html401/interact/scripts.html#adef-onfocus> meta note 2: all quotations from the HTML4 technical recommendation which pertain to LABEL and its interaction with form controls derive from the HTML 4.01 Technical Reference--in particular: http://www.w3.org/TR/html401/interact/forms.html#h-17.9.1 meta note 3: this post fulfills the action item noted in the minutes to the supplemental 18 may 2001 telecon as: <QUOTE> 11. DP and GR: Produce an example scenario to justify this checkpoint 9.5 and to satisfy Issue #482 Source: http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0164 </QUOTE> aloha, y'all! at last thursday's teleconference, david and i took an action item to (a) develop a list of destructive/detrimental scenarios involving the use of the "onfocus" event handler, defined in the HTML 4.01 Technical Recommendation at: <http://www.w3.org/TR/html401/interact/scripts.html#adef-onfocus> and (b) develop test cases that demonstrate situations in which not automatically firing an onfocus handler would improve access... we need a test case for each element for which onfocus is a valid event handler in HTML4; to further that end, i've started working on some test pages, based upon the following list of onfocus test cases, drawn mainly from onfocus events that have been encountered "in the wild": 4A) onfocus on A Scenario 4A1: pop-up window spawned when link receives focus 4B) onfocus on AREA Scenario 4B1: automatically opens referenced document in new window when the AREA receives focus 4C) onfocus on BUTTON Scenario 4C1 (harmful): auto-submission of form onfocus (that does NOT constitute an explicit user request) Scenario 4C2 (potentially helpful): pop-up when BUTTON receives focus: "Clicking on this button signifies that you have read and agree to our _terms of service_. All sales are final." 4D) onfocus on LABEL Question 4D1: isn't "clicking" on a LABEL or establishing focus by invoking an ACCESSKEY defined for a LABEL supposed to automagically activate the associated FORM field? isn't that an intrinsic onfocus event defined for LABEL by spec? the HTML4 rec states: "When a LABEL element receives focus, it passes the focus on to its associated control." is onfocus for LABEL, therefore, intended as built-in redundancy or as a means of enabling other events, such as popping up a "help" window, to automatically fire when the LABEL receives focus? is it intended to "extend" the functionality of the LABEL element? if so, isn't that potentially (if not inherently) problematic, since, by spec, establishing focus on a LABEL is equivalent to establishing focus on the associated control? yes, attaching an ACCESSKEY to a LABEL makes it an enabled element, even if scripting is turned off or not supported, but how would one establish focus on a LABEL using an audio-only UA, especially since doing so is, by spec, supposed to pass focus to the form control associated with it via an ID/FOR reference? is the programmatic action: "when INPUT contains an 'id' speak the content contained in the LABEL defined for the INPUT with an identical 'for' value" establishing focus, even if the query isn't performed via the DOM? moreover, the HTML4 technical recommendation's stipulation that "Each LABEL element is associated with exactly one form control" is an assertion of equivalency, for--while multiple LABELs can be associated with a single form control, all individual LABELs are inextricably bound to a single form control... no matter how many LABELs reference an individual form control, there is a semantically hardwired equivalency relationship between the LABELs and form controls--the ID/FOR referential relationship... which is why i don't understand why there isn't a specified stipulation that--at least for form controls--either only one of an associated pair (or grouping) is allowed to carry an onfocus event handler (preferably the form control) or that only identical/redundant onfocus events can be defined for each individual component of a referential relationship in which the binding intrinsic event is the passing of focus from one element to another in a semantically hardwired equivalency relationship: INPUT for machine processing, LABEL for human processing... unless someone can convince me otherwise, i believe that the inclusion of the onfocus event handler in the set of attributes for the LABEL element to be an error in the spec--if the onfocus event defined for a LABEL and its associated form control aren't identical, then the model (LABEL equals form control) breaks Question 4D2: should technical/philosophical discussions of the UAAG implementation test pages be conducted in parallel on w3c-wai-ua AND wai-xtech or on only one or the other? should the technical details (what will be tested, how the test is constructed) be carried on in w3c-wai-ua and the technical/philosophical discussions arising out of the UA discussion be carried on in wai-xtech? 4E) onfocus in SELECT -- DONE: http://www.hicom.net/~oedipus/wai/ua/tests/onfocus_form1.html and http://www.hicom.net/~oedipus/wai/ua/tests/onfocus_form2.html (the second form contains a SUBMIT button, the first does not) NOTE: the accesskey to get to the FORM on all single-form test pages linked off of http://www.hicom.net/~oedipus/wai/ua/tests/ is 'f') WARNING: it isn't easy to get back to this page using the back button in many GUI browsers because the last item with content focus has an onfocus event handler associated with it); this "endless loop" behavior is not only inescapable if one isn't using a pointing device; the resultant inability of the user to get return to the point at which he or she was before the firing of the onfocus event is a compelling reason to accord suppression of automatic firing of event handlers a Priority 1, as is the automatic firing of an event handler when an AREA or link receives focus, due to the users' inability to return from whence he or she came... NOTE from GJR: i defy anyone using the keyboard alone in conjunction with a current implementation that supports scripting to return to the test page _after_ having been cast off to the guidelines--i've tried innumerable times, and even though i've been quick enough on occasion to hear JFW read a hyperlink to which i attempted to tab, the form control to which the "onfocus" event handler is attached retained focus, and had already initiated the fetch for the UAAG; without the ability to suppress "onfocus" events, it is a truly Sisyphusian task; this, combined with auto-submission achieved by attaching an "onfocus" event handler to the BUTTON element certainly rises to the P1 level--especially since the proscription against submitting forms without an explicit user request is also only a P2. 4D) onfocus in TEXTAREA Scenario 4D1: when TEXTAREA receives focus, pop-up window containing "helpful hints" or a "privacy policy", such as "we won't sell your address to third parties" is spawned; JavaScript that generates the spawned window/UA instance will be functionally stripped-down (bereft of a menu bar, scrollbar, etc.) Scenario 4D2: when TEXTAREA receives focus, placeholder text in TEXTAREA appears; Scenario 4D3: when TEXTAREA receives focus, placeholder text in TEXTAREA disappears; a final suggestion: as a result of our action item, we respectfully submit that the order of checkpoints 9.4 and 9.5 be reversed--unless you can suppress the automatic triggering of an event handler, how can you possibly query it in order to obtain the list of input device event handlers associated with that element? 9.4 breaks unless a UA satisfies 9.5, _especially_ in the case of "onfocus" events... since they are both P2 checkpoints, the only effect on the document that switching their placement should have is to increase the logical flow of the checkpoints gregory and david (with an appreciative nod to dave pawson for providing feedback on the test pages) ------------------------------------------------------------------ ACCOUNTABILITY, n. The mother of caution. Ambrose Bierce, _The Devil's Dictionary_ ------------------------------------------------------------------ Gregory J. Rosmaita: oedipus@hicom.net Camera Obscura: http://www.hicom.net/~oedipus/index.html VICUG NYC: http://www.hicom.net/~oedipus/vicug/index.html Read 'Em & Speak: http://www.hicom.net/~oedipus/books/index.html ------------------------------------------------------------------
Received on Wednesday, 23 May 2001 05:02:13 UTC