- From: Al Gilman <asgilman@iamdigex.net>
- Date: Sat, 15 Mar 2003 08:32:16 -0500
- To: w3c-wai-ua@w3.org
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