Re: LYNX-DEV improving on [IMAGE]

[Al Gilman]

  From: Foteos Macrides <address@hidden>
  Subject: Re: LYNX-DEV improving on [IMAGE]

  address@hidden (Philip Webb) wrote:
  >970604 Robert Bonomi wrote: 
  >> I'd like to propose that this toggle display things, not as  "[IMAGE]",
  >> but as "[{name}]", where "{name}" is the 'least significant component'
  >> of the fully-qualified pathname of the image.
  >> e.g. "[CORPINFO.GIF]"  for <IMG=/disk2/home/www/images/corpinfo.gif>.
  >> 
  >an excellent idea, if it's easy to program.
  
        It's easy to program, but consider this.
  
        If you set advanced mode, the URLs for links, including those for
  binaries when you've toggled on creation of links for them, are displayed
  in the statusline, so you would see corpinfo.gif there.  The pseudo-ALTs
                                  ^^^
Advanced screen-reader users do set up special sensitive regions on the
screen so that the status-line display works for them.  Entry-level
screen-reader users haven't mastered this and the status line is not
a help to them.  More appropriate link text would help these and improve
delivered page quality for all.

  for such links are not only "[IMAGE]", but could instead be "[INLINE]",
  "[FIGURE]", "[OVERLAY]", "[APPLET]", "[BGSOUND]", "[EMBED]", "(OBJECT)",
  or "(IMAGE)" depending on the type of binary and markup with which it is
  associated, and this information would be lost for the "benefit" of using
  the filename, which you could see in the statusline without losing that
  additional information.  Also, when you insert such psuedo-ALTs, you
  distort the intended formatting, and the filename could be longer than
  the informational pseudo-ALT, causing greater distortion.

The last proposal that I recall passing around here included both
type and content indications in the synthesized link text.  It
does not need to be an either/or.
  
It may even be worth additional HTTP hits to get adequate link
description.  This topic is discussed in my "percolation of
descriptive information" notion and is the subject of a current
"D-tag or D-link" action item in work in the WAI.

On the whole, what we do in Lynx with links that lack appropriate
ALT strings is not disturbing "the intended formatting" because
the authors never looked at or thought about how the page would
be formatted by Lynx.  OTOH I fully agree that ALT="" should be
respected, at least for the initial formatting, because these
authors meet prima_facie tests that they thought about it.
And for "try harder" exploration when the author figured wrong,
the l)ist_links command already does the trick.

        All things considered, this oft' expressed idea might not be
  execellent. :) :)
  
I won't claim to have considered all things.  Just a few more.
And I'm not sure we have an excellent solution, yet.  It seems to
me that the evidence suggesting "There is something better to do
than what we do now" is plausible.  The WAI is keenly aware that
there is a problem that needs to be addressed.

--
Al Gilman

WAI refs: http://www.access.digex.net/%7Easgilman/web-access/
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;