Re: ALT content question

  From: Daniel Dardailler <danield@w3.org>
  
  Al wrote:
  > They are both inappropriate.  The ALT text should be
  > 
  > 	W3C Projects Status
  and 
  > The anchor content should advise you what is at the far end of the
  > link.  
  
  
  Shouldn't the TITLE attribute convey the information about the
  destination of a link ?
  
I have only tried two, by I have yet to find a browser that does anything
useful with the TITLE if it is annotated onto this anchor in the HTML.
This raises the question: "For the purposes of what timeframe are you
asking?  Now or in the ideal future we want to migrate toward?"  In 
what follows I will try to separate responses related to a) best workaround
now and b) framing requirements for a better solution.

  I'd rather separate the meaning of the image from the meaning of its
  application in a particular context using different attributes.
  
  e.g
    <IMG SRC="w3clogo.png" ALT="W3C logo">
  is one thing
  and 
    <A HREF="http://www.w3.org" TITLE="W3C Projects Status">
       <IMG SRC="w3clogo.png" ALT="W3C logo">
    </A>
  
  (TITLE is now a core attributes in Cougar but was in A since day one)
  
It would appear from my cursory examination to be an un-implemented
attribute.  In the here and now, you only get one shot.  The priority
[which is use-based] of informing the user where they are about to
go is higher than the priority of describing the image.  [sorry, image.]
Given the currently deployed client behavior [range] the best workaround
now is to use the ALT tag for an alternative anchor content (like its
acronymous name) and not for a descripiton of the image.

In terms of framing the context for a solution, I 100% agree that the
model of the process has to distinguish three things:

	1 - the a_priori characteristics of the resource
	2 - the a_posteriori characteristics of the local substructure
		created by the use of the resource
	3 - the tailoring information which must be applied in the
		invocation operator so as to transform 1 into 2.
 
On the other hand, it is premature to think we know what subset of
this information wants to be in HTML and what wants to be accessed
by more HTTP.  Please return to my "percolation" white paper starting
at http://www.access.digex.net/%7Easgilman/web-access/announce-two.html
for an introduction to how there is a tradeoff between data and 
action solutions to this need.

  > If this image were not the content of a link, but used to frame
  > the signature section of the page, the ALT text is better "W3C"
  > and not "W3C logo" if the browser is Lynx.  In Netscape with the
  > graphics turned off, I might prefer "W3C logo."  In speech, ...?
  
  You realize of course that it's better not to depend on a particular
  browser, but could explain why one is better in one context.
  
For the long term, I am in 110% agreement with this point.  I could
have said

 80X24:	For a browse where the display medium is 24 rows
	of 80 monospaced characters each

 VGA16:	For a browse where the display medium is a graphical
	slate of minimum 640X480 pixels each capable of
	at least 16 colours.

But in order to be brief in email I said "Lynx" and "Netscape" 
instead.

For the purposes of here-and-now guidelines it is absolutely
necessary to deal with the demographics of browser behavior
for the browsers (including versions, sigh) in the field now.

It is hard to discuss what "should" be in terms of this example,
because a more use-related image "should" appear as the content
of this link, if a link is needed.

More likely, the need to identify the corporate author is more
important than the need to provide yet another link to the top of
the presentation.  Assuming that that is the basis for using this
image, it belongs in the GUI presentation of the file.

Independent of use, this image has a variety of text
descriptions:

	Text content: W3C
	Title: W3C logo
	Description: The W3C acronym displayed in a box.  Capital
		W and numeral 3 are in one colour and Capital C
		is in another as a allusion to _the derivation
		of the acronym_.

Here I have surrounded with underscores text which should be an
hyperlink to an explanation of the derivation of the acronym.
Note the emergence of requirements for HTML in descriptions.
Descriptions for sensitive maps should also embed all the links
in the map.

To return to "how to meet the need represented by the use:"

What I haven't got across well enough yet is how little is lost
if the presence of this image is entirely hidden in the 80X24 and
particularly non-visual browse.  Suppose that browsers did
display the TITLE tag in a way that would replace the image as
the content of the anchor.  Then for 80X25 and pure audio
browsing, the preferred ALT text would be ALT="" i.e. hide it
entirely.  The slide bearing this example image and link is full
of pro-forma navigation aids.  As the size of the display pipe
goes down, more and more of this infrastructure wants to migrate
into implicit information displayed only on explicit request and
not be presented in the default "display" view.

Appropriate accomodation of browsing is not just changing or
stripping fonts.  The focus or viewframe is going to be scoped
differently, as well.  Not only breadth of topic but in depth of
detail, as well.  One way is for the content form to contain
priorities and the preferences to play off the priorities to
prune the data presented.  That is what this slide would take to
morph it gracefully all the way to audio.  The navigation buttons
would not turn into presented audio but be aliased to standard
navigation commands.  

The more we expand the data model, the more important it is to
understand that there will want to be filter-driven hiding on the
way to the non-visual browse display.

What do you think, Mark?  Am I in the ballpark?

--
Al Gilman

Received on Monday, 9 June 1997 14:29:27 UTC