- From: Jim Thatcher <thatch@attglobal.net>
- Date: Tue, 05 Jun 2001 09:27:46 -0500
- To: "gregory j. rosmaita" <oedipus@hicom.net>, w3c-wai-ig@w3.org
Gregory, Just a clarification of the example. The fact that my example does not speak is sort of the problem. Today Window-Eyes will speak all the titles of those input cells. I have been told that JFW will support titles on input elements soon; same for HPR. The point is that you can capture the intended labeling with titles. Phill's proposed change to LABEL (or some variation) is great, but that is a long term solution. We need a solution today for forms with complex layouts - not necessarily the simple rectangle of the example. Jim jim@jimthatcher.com Accessibility Consulting http://jimthatcher.com 512-306-0931 -----Original Message----- From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On Behalf Of gregory j. rosmaita Sent: Monday, June 04, 2001 2:44 PM To: w3c-wai-ig@w3.org Subject: labeling controls in tabularized forms (was Re: Proposal for fixing label) aloha! PJ: Again, this is trying to solve the problem when you have form INPUT elements laid out in a table with the "labels" as headings over the columns or rows. See Jim's example http://jimthatcher.com/simpleformwithtitles.htm GJR: i did try out jim's example using JFW 3.70.87 and none of the titles associated with the edit fields were automatically spoken as i tab-navigated the form -- all i heard was: edit box TAB edit box TAB edit box TAB edit box issuing the "Speak Current Control Label" keystroke command (Instert+TAB) resulted only in a repetition of the default string "edit box" -- note that this command works when a LABEL has been associated with a form control querying the form's control using JFW's "Keystrokes for Working With Tables" didn't provide any labeling information either: 1. issuing the JFW command for "Say Current Cell", ALT+CONTROL+NumPad5, whilst in an edit box in thatch's example yields only "edit box" 2. issuing the JFW commands for "Speak Cell to Right", "Speak Cell to Left", "Speak Cell Below", or "Speak Cell to Right" all resulted in JFW informing me that i was "not in table" i've been preparing a few test forms of my own for distribution to the IG list, in part to discover what works given the state-of-the-art today, as well as to explore, more fully, the implications of each approach... the first, tabular_forms_using_label.html, contains three forms, all of which are extrapolations upon the form which started this thread, the "Web Search" form located at www.wirednews.com -- they are all rather simple examples, although with each iteration, the tabularization becomes a bit more complex... of the 3 examples contained on the page, only the third is problematic when linearized... the second file, tabular_forms_using_label2.html, is a demonstration of a tabularized table that does not unroll (linearize) gracefully, for whose form controls both labels and accesskeys have been defined the third file, tabular_form_using_title_and_alt.html, is a re-iteration of the form contained in the second file, with all of the LABELs removed -- rather, descriptions have been bound to individual form controls using the appropriate attribute: ALT for INPUT (as per http://www.w3.org/TR/html4/INTERACT/forms.html#h-17.4 in which ALT is specifically defined as providing a "short description" for the SELECT element} and TITLE (as a generic attribute) for SELECT... as in jim's example, i find it extremely difficult to obtain any substantive information from individual form controls using JFW 3.70.47 a few observations/comments on the third file: 3a) ACCESSKEY is not a valid attribute for SELECT... while, personally, i believe this to be an error in HTML4, i do think it was a conscious decision on the part of the HTML WG for 2 reasons: 1. "accesskey" _is_ a valid attribute for LABEL 2. the HTML4 spec states unequivocally at http://www.w3.org/TR/html4/interact/forms.html#h-17.9 that: <QUOTE> Some form controls automatically have labels associated with them (press buttons) while most do not (text fields, checkboxes and radio buttons, and menus). For those controls that have implicit labels, user agents should use the value of the value attribute as the label string. The LABEL element is used to specify labels for controls that do not have implicit labels, </QUOTE> 3b) JFW's enunciation of descriptions defined using ALT and TITLE is capricious at best... in particular, none of the descriptions defined for the SELECT OPTION controls using "title" are enunciated by JFW -- instead, only the currently selected OPTION defined for the SELECT control is spoken (note that, if the "selected" value defined for the SELECT control is displayed, JFW speaks the "name" defined for the SELECT control as well as the currently selected OPTION) 3c) using the deprecated U element, rather than a span classed to apply the text-decoration:underline style rule to the character employed as an accesskey, to visually indicate the accesskey defined for a form control minimally improves JFW's attempt to speak a description for the form control -- consult the fourth attached file: tabular_form_using_title_and_alt.html the fifth file, tabular_form_using_label_and_alt.html, employs all of the methods utilized in the preceding 2 examples: LABEL, "accesskey", "title", and "alt" -- this is the "hedged-bet" example... using JFW 3.70.47 to traverse this form, i hear: 4a) the contents of each LABEL associated with an individual form control; 4b) an indication of the "accesskey" defined for the form control when the label is spoken after the form control for which it was defined receives focus (this is not due to the aural styling defined for the class="accesskey" but a default setting on the part of JFW do indicate internal anomalies in spelling/capitalization/emphasis within a word) 4c) the default value for the form control with focus caveats: the first form control -- the "What Do You Want to Find?" edit box -- has 2 labels associated with it, but only the first LABEL is spoken by JFW 3.70.47, although sighted users whom i've asked to test these forms have confirmed that "clicking" on either of the labels defined for the first form control causes focus to be passed to the form control with which the label is associated, as per http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1 which states: <QUOTE> When a LABEL element receives focus, it passes the focus on to its associated control. See the section below on access keys for examples. </QUOTE> something which i attempted to signify visually by using CSS to associating a "dynamic outline" with the LABEL element, as defined at: http://www.w3.org/TR/CSS2/ui.html#dynamic-outlines but none of the UAs used to test the forms so far (IE 5x, Mozilla 0.9, Opera 5) seem to support the type of dynamic outlining that would indicate to a user, OnMouseOver, that the LABEL is an enabled element... gregory. ------------------------------------------------------------------ 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 Tuesday, 5 June 2001 13:44:10 UTC