Re: "tool tip" - alternate use of ALT

Hi AL,                            CONTAINS PROPOSAL

I wrote:
> > - The argument ALT text can so serve to targets does not work 
> >   since designers will ONLY serve and follow their main group of
> >   potential users and use local guidelines for the contents
> >   of the text in the ALT-attribute.
> > 

Al Gilman wrote:
> I think that what the GUI users would expect to read in a tool
> tip is something we don't know.  We should understand it better
> before we assume it is different from the information we need;
> Or assume it is the same, for that matter.

This is not an approach I expect in this group.
At first I would like to stress the need for an alternate
descriptive text feature. For this the ALT-attribute can be used
unless other groups of users do not want to use it for other 
perposes. 
The reason I found out about it was in my own office where they use:
- small images as button (looks great)
- use the "tool tip" to describe the action, but have the reasonable
  rule NOT to use the tool tip if the text is the same
  as the button shows since this looks stupid to a gui-user.

The approach we need is that we have a solution that assures an
accessibility add-on in stead of other rules to fight against.

> There are a variety of ways that the HTML can provide text
> content for a tool tip: ALT on images, TITLE on anchors,
> onmouseover scripts on almost anything.
> We should not assume that the demands for information from the
> GUI-using browsing public will be different from the demands of
> the eyes-free browsing public.  We should first try to do some
> market research on the visual-presentation information fields
> like this tool tip.  Find out what the browsing person that is
> looking at a GUI screen would want in that space.  If it fits our
> need, we should use that information in the eyes-free context,
> too.  

I feel free to express the opisite:
We already experience what GUI-users expect, want and use.
We do not have the time nor the means to do any research in this
field. You might well expect GUI-users will expect/need something
else than we do. 
We work here to find solutions for us not to find solutions for 
others.

Why is the ALT-atrribute used (ihn image)?

===== My proposal to the HTML groups is to add the "TOOL_TIP"-attribute
      to reach homogeenieous use for this useful thing and to 
      free other attributes (like ALT) for there origional use.
> 
> We should not ask for fields dedicated to eyes-free consumers
> unless we have exhausted our possibilities for sharing
> information with the majority.

> I am hopeful that the information the eyes-free browsing
> individual needs is information that the eyes-first browsing
> individual will want at certain times.  This is content that is
> presented to the eyes-free customer all the time and to the
> eyes-first customer part of the time.  If we can express our
> needs in terms of information topics that the GUI user wants, at
> least sometimes, and associate HTML text spaces (elements and
> attributes) with those topics, we have maximized our "universal
> design" quality rating.  And we will get the information the
> eyes-free need in more HTML pages than if we define the
> categories or topics to be filled in in some other way.

I heavily support this argument, but not if it costs accessibility.
In the current approach the ALT-attribute will most likely not serve
anymore.
> 
> There is an unresolved area that the markup guidelines and
> browser guidelines working groups need to team up on.  This has
> to do with what goes in ALT as we have richer options in terms of
> other attributes with related uses.  We need a migration plan by
> which we can get from
> 
> A: the situation now when information demands are fighting over
> the space in the ALT string because that is all that gets
> consistently displayed by browsers, to
> 
> B: a better future situation where the breadth of attributes
> including not only ALT on images but also TITLE on links etc. are
> displayed enough by browsers so that authors use them in
> discriminating ways and the eyes-free browse presentation has the
> information it needs in a syntactic place it can count on.
> 
> We aren't at B yet.  It takes sending compatible messages to the
> browsers writers and page writers to get there.  I think that
> with 4.0, including the attribute additions that the HC team
> recommends, HTML gives us enough information buckets to fill.
> 
> We still need a better story as to what information goes in what
> buckets so that browsers can pull the right information at the
> right times.  There is time to publish this story in the Markup
> Guidelines and Browser Guidelines.  We don't have to have the
> answer all worked out by Wednesday.  But we do need to recognize
> that there is work remaining to be done to get our story
> straight.

I fully agree on the buckets philosophy.
If this problem is not solved in HTML 4.0 it is up to us to highlight this
if we are about to have negative spin offs.


> I think that the presence of tool tips in the GUI presentation of
> a page is on the whole a positive influence on our success in 
> getting needed information into HTML pages.
> 
> People using GUI screen readers need to have the capability to
> turn them off, and things like that.  But I think that we can make
> the tool tip a friend if we approach it right.

In theory you are right, but 
A: Turning of pictures is only requested if line performance problems occur.
   This problem will disappear in the near future.
B: If GUI-users / designers use the ALT-attribute for alternate
   objectives GUI-specific rules will apply. This is the problem.
   So not a technical problem but a disign conflict.

I do hope my explanation is clear enough not to move this from the agenda.

Best regards,
Jaap

Message from: Jaap van Lelieveld      The Netherlands
              Chairman of EBU commission on Technical Devices and Services
E-mail:       Jaap.van.Lelieveld@inter.nl.net

USING: YARN V0.92 as an offline reader, and
       UQWK / OLMENU under UNIX for mail and news transfer

Received on Monday, 20 October 1997 15:21:17 UTC