[unofficial] prognosis for official erratum on altAsToolTipRepairNNN

At 11:46 PM 2003-03-10, Aaron Leventhal wrote:


>The issue is what to do on mouseover for <html:img>html:img, etc. when 
>there is no TITLE attribute, but there is an ALT attribute.
>
>* "Joe User" wants to see ALT text show in a tooltip on mouseover, 
>especially for older sites which will never be changed to use TITLE for 
>this purpose. He's used to mousing over to images (e.g. news topic images) 
>to see some related text. IE, Netscape 4.7 and other browsers do it, so 
>Mozilla/Gecko/Netscape seem broken when they don't. It makes him mad 
>because web pages aren't working the way he wants.
>* "Standards guy" wants to do the right thing relative to W3C standards. 
>He says that ALT should never be used as a replacement for TITLE, because 
>they have two distinct purposes. He says that ALT is meant to be an image 
>replacement, and TITLE is meant to be used for tooltips. He believes that 
>blurring the line between the two will ruin the web because people will 
>write poor ALT text. It makes him mad that people don't understand that 
>web standards are important.

>It's difficult to summarize the 
><http://bugzilla.mozilla.org/show_bug.cgi?id=25537>flamewar, which has 267 
>comments so far, but I'll do my best:

I don't understand this part.  It's a longstanding problem and that's about 
the best summary
of the problem I have seen.

>I believe a standards case could be made to support either argument -- 
>which is why I think it would be helpful for the W3C to have an official 
>position on this exact situation (call it dueling text equivalents if you 
>like) to finally settle the argument. I hope the question isn't too 
>specific for that.

[nit: not dueling text equivalents.  The case in question is about the
cases where there are zero or one text annotations on the image.  It would
be closer to say dueling attribute names for the half-clued author who
provides a text annotation because the browser flips a tooltip if she does.]

Given the run of historical precedent, I would suggest that it is unlikely
that the W3C would come up with an up-or-down answer on this as an official
interpretation or erratum clarifying how to apply the several
Recommendations in this area.

Stating that one behavior is right and another is wrong is the sort of thing
that the W3C would regard as a heavyweight change in the HTML spec, at
least, and the HTML WG is working changes like that in the XHTML 2.0 context
and would be unlikely to decide (or find time to) issue such a decision via
the erratum mechanism.

Secondly, the approach that has been taken over and over again in UAAG and
WCAG has been to retreat from normative provisions in format-specific
questions.  [The ATAG is mostly derived from these two in this kind of area.]

So for the UA WG to consense on this point of format-specific usage as in
any sense a final answer would be inconsistent with the sense of the
deliberations back when the UAAG was cooking and we had a better sample of
representative stakeholders actually plugged into the proceedings.

However, given that 'less-than-likely' caveat, here goes.

If you were to get an official position out of the W3C it would probably be
on the 'standards guy' side.  More senstitive to the fact that tooltip
behavior encourages bad ALT phrase content choice than sensitive to the
problem of educating zillions of amateur authors.

If we were to generate such an official statement supporting the 'standards
guy' position, it would probably be ineffectual, other than to allow the
thread on your list to be extinguished.  IMHO it is unlikely that we are
going to get this behavior expunged from any browsers other than Mozilla and
its derivatives.  This fails to make critical mass in terms of the popular
understanding of the markup and would hence not change the bulk of author
behavior much.  Not ease the pain of either Joe User or Standards Guy.

There is a problem with the design of the data format that leaves us with no
really good choice.  The low-bandwidth user wants a description of the image
as link text for a download to populate the image in place in the current page.
The screen reader user wants a functional replacement of the image which is
often different.

A good ALT text (presuming the functional equivalent sense) looks dorky when
displayed as tool tip.  The user's reaction is "but, I know that."  The natural
tendency of authors populating what they in their gut sense as a tool tip text
is to put _the second line_ of a title for the image.  Supplemental stuff,
not starting at the top where one needs to start if the image is not visible.

But the authors in question won't put in a TITLE if the ALT doesn't pop up --
they will just leave the image un-annotated in many cases.  Is a bad ALT
better than none?  This is where reasonable people may reasonably differ, and
Joe User and Standards Guy will surely differ, not being constrained to be
reasonable people when listserving.

A plausible model for a new markup grammar is a two-part Title:  There is a
nominative part that is the [closest thing to the current] ALT and is shown
in confined circumstances (voice among them) and which provides the top of
the information tree that serves as a functional replacement for the image
when the image is not perceived.  The second part of the Title is an
expansion which is supplemental to the first part.  The long form of the
Title is the whole text with first and second parts included.  The long form
is shown, for example, in an 'information page' view, but not read normally
on the fly.  'Information page' style is a screen-size-dependent option in
the context menu.  By the way, there is a verbose option for the context
menu that includes a 'you are here' breadcrumb trail including intrapage
orientation and hence would use this for example if someone requests the
context menu with right mouse button under screen magnification when over a
sensitive area in an image map. There are verbose options that force the ALT
behavior to the long form and the tooltip to the long form.  These options,
however are unset in the shipping defaults.  The second part is the default
tool-tip content when the image is present and the user passes the pointer
by the image (configurable to suppress).

Note that this is sympathetic with demand coming into the Web from
mobile-device accomodation.  The Device Independence group.  They will have
use for short and long versions of labels (such as the Title discussed above).
So there is some hope of authoring tool support for this level of
sophistication.

[disclaimer]  I have a job-related bias as advocate for the 'fix the format
first' position.  But I don't think that we are going to win an EO war to
make the 'standards guy' sense of the respective roles of ALT and TITLE
stick as widespread understanding short of the deployment of XHTML 2.0.  And
the present markup doesn't let one do a job good enough to make that war
worth waging.  So we should hold off on the EO war until we have bashed the
SVG model of text annotations to incorporate the above segmentation of the
TITLE, or a functional equivalent that supports device independence
[semantically, facile adaptation to the situation in the actual use context]
better and concede the "alt as allternate tool tip, too" as current
most-common practice an stick to trying to propagandize the role distinction
between ALT and TITLE without the support of browsers failing to flip the
Alt at authors as a way of trying to entice them to use TITLE.

[If you can read that last paragraph you have been at this business too 
long...]

So, Aaron, that's why I don't think that W3C can give you real relief on
this pain, nor will it give you nominal relief.  At least I am not picking
up the gantlet to get you such a ruling at this time.

But please help us with our comments on XHTML 2.0 to see what data
structures would be intuitively authorable to act well under alternate
delivery-context behavior profiles.



>Ian and Jon,
>
>Thank you for all of the information regarding how the various UAAG 
>checkpoints relate to this discussion.
>
>First, let me address some points you have made:
>- We don't yet allow access to tooltips via the keyboard. As far as I know 
>there was a patch written to include access to this information in the 
>properties for any focusable item. It's often requested, especially for 
>ALT, not necessarily for TITLE.
>- It's possible to configure Mozilla so that ALT text is rendered in place 
>of an image.
>- We don't currently have a bug filed for the ability to suppress 
>automatic tooltips that occur on mouseover. No one has yet requested this.
>- I didn't realize that a tooltip was considered a separate viewport. 
>Although it does overlay the contents of the screen, I'm not sure whether 
>it should really qualify as a full-fledged viewport, although apparantly 
>that's been the intention of UAAG all along. I haven't researched that 
>issue at all.
>
>Anyway, I really shouldn't limit my question to how it relates to UAAG. 
>The flamewar in question is specific to HTML (so perhaps I should be 
>asking this question on the HTML list?)
>
>It's difficult to summarize the 
><http://bugzilla.mozilla.org/show_bug.cgi?id=25537>flamewar, which has 267 
>comments so far, but I'll do my best:
>
>The issue is what to do on mouseover for <html:img>html:img, etc. when 
>there is no TITLE attribute, but there is an ALT attribute.
>
>* "Joe User" wants to see ALT text show in a tooltip on mouseover, 
>especially for older sites which will never be changed to use TITLE for 
>this purpose. He's used to mousing over to images (e.g. news topic images) 
>to see some related text. IE, Netscape 4.7 and other browsers do it, so 
>Mozilla/Gecko/Netscape seem broken when they don't. It makes him mad 
>because web pages aren't working the way he wants.
>* "Standards guy" wants to do the right thing relative to W3C standards. 
>He says that ALT should never be used as a replacement for TITLE, because 
>they have two distinct purposes. He says that ALT is meant to be an image 
>replacement, and TITLE is meant to be used for tooltips. He believes that 
>blurring the line between the two will ruin the web because people will 
>write poor ALT text. It makes him mad that people don't understand that 
>web standards are important.
>
>I believe a standards case could be made to support either argument -- 
>which is why I think it would be helpful for the W3C to have an official 
>position on this exact situation (call it dueling text equivalents if you 
>like) to finally settle the argument. I hope the question isn't too 
>specific for that.
>
>- Aaron
>
>
>
>My question is basically (b) as you have outlined below.
>
>Ian B. Jacobs wrote:
>>
>>On Mon, 2003-03-10 at 12:32, Aaron Leventhal wrote:
>>
>>>
>>>What is the UAAG's position regarding the showing of alt text as tooltips?
>>>
>>
>>
>>Hi Aaron,
>>
>>To help keep this discussion focussed, I'd like to clarify:
>>
>>a) Are you asking very generally "Are tooltips ok, whatever their
>>    source in the document?" Or, "Is it ok to pop up a small window
>>    to present information to the user on hover?"
>>
>>b) Are you asking "In HTML (or some other format), what are legitimate
>>    sources of text that a user agent could consider for a tooltip?"
>>    And in particular, "How do I deal with the presence/absence of alt
>>    and title?"
>>
>>If the answer is (a), then I hope my points that follow will contribute
>>to this discussion; they are not an official UAWG position. If the
>>answer is (b), then I think that we will need some help from XAG
>>as well.
>>
>>About (a):
>>
>>  1) The text that you are talking (alt) about is "conditional content"
>>     in UAAG 1.0 terms.
>>
>>  2) Checkpoint 2.3 requires that all conditional content be
>>     available to the user. A tooltip (i.e., popup window) would satisfy
>>     the requirement (see 2a in particular) of making conditional content
>>     available to the user.
>>
>>  3) Checkpoint 1.1 requires that the user be able to operate the user
>>     agent entirely through the keyboard. If the ONLY way to get at
>>     tooltip text is "onMouseOver" then the user agent has not met 1.1
>>     for providing access to alt.
>>
>>  4) In UAAG 1.0 terms, a tooltip window is a viewport since the user
>>     agent renders content through it. Checkpoint 5.3 applies: allow
>>     configuration so that the tooltip only opens on explicit user
>>     request. This means: allow config for no automatic tooltip popups
>>     and allow the user to get at that information "manually," e.g., by
>>     querying the element that has alt specified.
>>
>>  5) Checkpoint 6.6 applies as well: provide programmatic notification of
>>changes to content, states and values of content, etc. This means
>>     that ATs should have access to the change of state (i.e., the pop
>>     up event). ATs also have access to the text content through other
>>     APIs.
>>
>>Could you summarize the various positions of the flame war?
>>
>>Thanks Aaron,
>>
>>  _ Ian
>>
>>
>>>
>>>Or, if there is no official position. What do individual members think?
>>>I'd like to see a civilized discussion, and if possible get an official
>>>position on it from W3C. It would be great for Mozilla if the W3C would
>>>say somewhere specifically "yes" or "no" to this. We have too many flame
>>>wars back and forth about it in bugzilla. I understand that the specs
>>>can be read to support either position, but I'd rather get something
>>>precise from W3C that will put an end to the flamewar.
>>>
>>><http://bugzilla.mozilla.org/show_bug.cgi?id=25537>http://bugzilla.mozilla.org/show_bug.cgi?id=25537
>>>
>>
>>
>>

Received on Saturday, 15 March 2003 13:02:43 UTC