- From: gregory j. rosmaita <oedipus@hicom.net>
- Date: Wed, 6 Jun 2001 03:43:08 -0400
- To: <w3c-wai-ig@w3.org>
aloha phill!
PJ Question 1. How does a developer offer advisory information about the
control and
also label it?
use FIELDSET, LABEL, and TITLE?
GJR: if you believe that the purpose of the "title" attribute is to provide
advisory information about the control, then, yes, one should first:
(a) group related controls using FIELDSET
(b) provide a caption for the FIELDSET using the LEGEND attribute
(c) provide a LABEL for each form control
before defining appropriate "advisory" text for each form control using the
"title" attribute...
personally, i would rather the content of the "title" always be a plain text
mirror of the content of the LABEL, than it be used to provide "advisory
information about the control" -- exactly what kind of information? the
control type? if the AT is providing an interface to a "mainstream" GUI
browser, that browser's UI should reuse the standard control classes defined
for the OS or VM on which they are both running, which the AT should be able
to identify programmatically, without delay and in a manner that will be
readily/immediately comprehensible to the user... if we are discussing a
browser with a purely aural interface, then the audio-only browser needs to
provide a default style sheet in order to provide a consistent (yet user
configurable) audio UI in which earcons and cues replace the immutable
visual shorthand a graphical browser uses to indicate form controls and
groupings... for example, this cue-before or play-during event -- which
could be a canned audio file, such as a beep, or generated text, defined
using CSS' content property, whose articulation is controlled using CSS2's
aural properties -- signifies that the user has reached and is still in a
textarea field, the same way a visual browser provides or reuses a widget
set which communicates to the user, through visual shorthand, "here is a
free-form text entry field" or "here is a radio button--only one can be
checked at a time", and so on... or, one could do it explicitly (again,
triggered by user configuration) by tagging all radio buttons as radio
buttons simply by supporting CSS' pseudo-elemental content generation
model -- the :before and :after pseudo-elements, defined in CSS2, Section
12.1, and the content property, defined in CSS2, Section 12.2:
input[type|=radio]:before { content: "radio button"; display : inline; }
input[type|=checkbox]:before { content: "checkbox"; display : inline; }
input[type|=text]:before { content: "text entry field"; display : inline; }
input[type|=text]:after { content: "end text entry field" } /* optional */
input[selected|=selected]:before { content: "selected"; display : inline; }
/* previous assumes well-formed XHTML or strict HTML4 */
select:before { content : "select"; display : inline; }
select:after { content : "end select"; display : inline; }
option:before { content : "option"; display : none; }
textarea:before { content : "free-form input field"; display : inline; }
textarea:after { content: "end input field"; display : inline; }
...
and so on...
but, having proposed a restriction on the use of "title" -- namely that
"title" or "alt", in the case of SELECT, must not differ materially from the
LABEL defined for that form control, and having asserted that a form
control's "title" or "alt" text is/should be a plain text
description/equivalent for the form control, which could be used by a user
agent, such as Lynx or NetTamer to perform repair on tablized forms which do
not linearize well, by not rendering any LABEL found in a TABLE for which
"title" or "alt" has been defined, but, instead, rendering the content of
the "title" defined for a form control inline, immediately preceding or
following the form control -- i need to pause to ask if that would be either
practical or useful? the titles defined for the forms archived at a URI
almost as long as the preceding sentence:
<http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/att-0611/03-tabul
ar_form_using_title_and_alt.html>
mirror the label text, save for the visual/audio cue for the accesskeys
(which could have been added to the "title", but then one worries about the
available real estate--how much of a "title" can be squeezed into a tooltip?
does that upper bound vary with screen area/resolution? from OS to OS? does
it impact the ability of an AT to extract anything above that bound from the
UA's DOM [theoretically, there's no reason it should, but one never knows])
at what size does a tooltip become unusable? i know that in the windows OS,
one can change the size and other font characteristics for tooltips, but i'm
not aware of any "persistence" setting that would help a user examine a
tooltip using very high levels of magnification, for example
answer: user-configurable cascade: 1. offer 3 modes -- verbose, less
verbose, and terse (described in answer to PJ Q4, below); 2. offer user
options, such as those thumbnailed below (where parentheses separated by a
space symbolize radio buttons and brackets separated by a space symbolize
checkboxes):
HTML Forms
Form Control Verbosity
( ) Speak LABEL
( ) Speak TITLE
( ) Speak Longest
( ) Speak Shortest
Announce Number of Controls
( ) When Entering Form or Fieldset
( ) When Speaking Control Description
( ) Never
Indicate New Control Grouping
( ) No Indication
( ) Say Legend at Beginning and End
( ) Say "New Group" When Entering
the default cascade would be: speak LABEL; if LABEL is not present, speak
contents of "title" or "alt"; if neither LABEL, "title" or "alt" is present,
attempt repair (such as: scrape screen and speak adjacent/nearest text)
note that these options are similar to those offered by JFW 3.5.x and
3.7.x's HTML Options for "Text Link Verbosity" -- the default would depend
upon the mode chosen by the user: verbose, less verbose, and terse
PJ Question 2. How should the advisory title attribute be rendered in a
visual browser?
tooltip?
how in the audio browser?
some key to speak advisory information?
GJR: i'm still troubled by the pairing of the terms "advisory" and "tooltip"
with "title" -- after all, despite the implication inherent in its name,
that the tooltip is commonly used to expose the contents of the "title"
attribute in GUI user agents is the result of an original implementation
decision and almost everyone else working in the same modality jumping the
same train, not an after-effect of tooltips having been used to convey
information contained in "title"!
tooltip does not equal title, nor does it equal "advisory text", for "title"
is not intended to provide "advisory" information in the sense that tooltips
which pop up OnMouseOver icons in GUI applications are... moreover, the
tooltip is only one method used to expose the content of "title" used in
HTML/XHTML documents -- it could also be displayed in the status bar, in a
specially reserved area of the screen, which is what Opera's done (at least,
by default) since it began supporting "title" on links, and i believe
Opera's default tooltip behavior for a link is to expose the contents of the
"href" attribute... so in that wise, yes, a tooltip can be used to provide
"advisory" information, but then control over tooltip content, as well as
tooltip behavior, would have to be given to the user -- if the tooltip is
being used to display the "href", the "advisory text" needs to be exposed
somewhere, somehow, and users need control over the tooltip's persistence...
but still, "title" doesn't equal "tooltip" -- "tooltip" is just one
implementation for the exposition of the content of the "title" attribute,
just as a context menu is one method of exposing all of the
options/events/attributes defined for the element with focus...
to answer your question as regards an audio UA, yes, an audio browser would
have to provide a keystroke to query for advisory info (or a configuration
option where such info is automatically spoken) but that contradicts the
advice i think would be necessary to give authors -- replicate the content
of the LABEL in the "title" or "alt" defined for a form control... but, if
one takes the position that, where an explicit descriptive mechanism is
defined for a form control, it is OK to use "title" to convey "advisory"
text, then one would have to definitively answer my counter-questions to PJ
Q1, and consider asking the CSS & FP working group to add tooltip to their
UI Module, and to define persistence/duration rules for the tooltip as the
graphical expression/exposition of the content of the title attribute --
which begins to answer your next question:
PJ Question 3. Should the rendering be consistent from browser to browser?
GJR: in the past, i've mentioned it as one of the behaviors that CSS3 might
address, as long as it is addressing other UI state-change events, such as
control over cursor display, and behavioral extensions -- consult the
following exchange, for example, for a discussion of some pros and cons:
http://lists.w3.org/Archives/Public/w3c-wai-ig/2000JanMar/0655.html
http://lists.w3.org/Archives/Public/w3c-wai-ig/2000JanMar/0656.html
http://lists.w3.org/Archives/Public/w3c-wai-ig/2000JanMar/0659.html
http://lists.w3.org/Archives/Public/w3c-wai-ig/2000JanMar/0664.html
and for background:
CSS3 UI Module WD:
http://www.w3.org/TR/2000/WD-css3-userint-20000216.html
CSS3 Behavioral Extensions:
http://www.w3.org/TR/1999/WD-becss-19990804
PJ Question 4: So should the default audio UI model be to always read the
fieldset before each field, or only when it changes?
GJR: as long as it is user configurable (as outlined in my response to mike
scott's question about labeling groups of radio buttons, archived at:
http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/0523.html)
i suppose so...
the model is the same as when moving through groupings of control/function
types in dialog boxes in GUI interfaces:
1. a "beginner" or "verbose" mode would repeat the legend before reading
each label, and also announce the number and type of form controls in a
grouping when that grouping received focus (via tab-navigation or accesskey,
for example) if configured to do so; it would also speak the form control's
type and/or state, as well as the number of each form control relative to
the total number of forms controls contained in the fieldset as the user
moves through the fieldset (or when the form control receives focus via a
pointing device or accesskey) all by default, although the user could always
turn each option on or off as he or she became more confident with the UI or
as situations demand, such as when the submission of the form is going to
have a material impact upon the submitter's life;
2. in the "intermediate" or "less verbose" mode, the legend defined for the
fieldset is spoken/output when a form control contained in the fieldset
receives focus, and the number and type of form controls contained in the
fieldset are announced (something which the user should be able to suppress,
via configuration); as the user navigates through the fieldset, the label
for each form control and the number of that form control, relative to the
total number of form controls contained in the fieldset, is spoken/output as
the user navigates from form control to form control: in the scenario
outlined by mike and illustrated by the mock form archived at (obscenely
long URI warning):
<http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/att-0523/02-field
set_style_test-CSS.html>
when the user establishes focus on the first form control in the fieldset,
he or she would hear: "What Kind of Cheese Do You Want on Your Pizza? 3
radio buttons; mozzarella selected"; as the user tab-navigated the fieldset,
he or she would hear: "Cheddar, not selected, 2 of 3" and "None, not
selected, 3 of 3" -- reverse navigation through the fieldset from the last
radio button would sound like this: "Cheddar, not selected, 2 of 3";
"Mozzarella, selected, 1 of 3"; the user should also be provided with a
query mechanism by which he or she can review a legend defined for the
current fieldset on demand
3. in "advanced" or "terse" mode, the legend defined for the fieldset is
spoken or output to a braille display when a form control contained in the
fieldset receives focus, and, if the user so chooses, announces the number
and type of form controls contained in the fieldset; as the user
navigates through the fieldset, the label and state of each form control is
spoken/output; the
user should also be provided with a query mechanism by which he or she can
review a legend defined for a fieldset on demand
global verbosity settings which would control most, if not all, of the
configuration options requested above could and should be provided to the
user no matter which verbosity setting is currently active... JFW 3.7.4x
offers such global verbosity controls as:
[ ] application start message
[ ] control group name/label/prompt
[ ] control name/label/prompt
[ ] control type
[ ] dialog name/label/prompt
[ ] dialog text
[ ] document name/label/prompt
[ ] dialog text
[ ] error message
[ ] item number
[ ] item state
[ ] screen-reader message
[ ] position information
[ ] screen message
[ ] select
[ ] selected item
[ ] smart help messages
[ ] status information
[ ] tool tip
note: monitoring for tool tips works only if windows is running in 256
colors because tooltips are limited to 256 colors, and hence aren't captured
by JFW [or, at least, only capriciously) if the GUI is running in high
(16-bit) or true (32-bit) color... for most users, tooltips enter the aural
landscape almost exclusively by accident -- the system's pointer's
point-of-regard just happens to be hovering over a tooltip enabled icon or
control, although i believe that the sort of automatic labeling of graphics
in an application's chrome that is offered by JFW attempts to sniff out the
tooltips defined for each enabled graphical element by physically moving the
mouse cursor to each enabled graphical element in the chrome...
hope this answered your questions,
gregory.
--------------------------------------------------------------
CRITIC, n. A person who boasts himself hard to please because
nobody tries to please him.
-- Ambrose Bierce, _The Devil's Dictionary_
--------------------------------------------------------------
Gregory J. Rosmaita, oedipus@hicom.net
Camera Obscura: http://www.hicom.net/~oedipus/index.html
--------------------------------------------------------------
Received on Wednesday, 6 June 2001 03:42:20 UTC