onfocus scenarios and tests

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