24125 - Support the 'name' attribute in the alt text generation algorithm

Status: VERIFIED DUPLICATE of bug 41924

(Core :: Layout, defect, P5)

Description

[Hixie (not reading bugmail)]

As per our e-mail discussion, this is just a reminder that we should also be
checking for the "name" attribute (after "alt" and "title") when generating
alternative text for broken (or disabled) images.

Comment 1

[Hixie (not reading bugmail)]

Stealing QA contact. Lowering priority. Moving out to M18. Adding dependency on
1994 and from 7954.

Comment 2

[troy]

Okay, I added a local function GetAlternateTextFor() and implemented it so that 
for an IMG element we use (in this order): ALT, TITLE, filename. And for INPUT 
elements we use: ALT, TITLE, NAME

Comment 3

[Hixie (not reading bugmail)]

Per HTML4.01, the NAME attribute also applies to IMG elements. And if an image
INPUT element is missing the ALT, TITLE _and_ NAME attributes, then we should be
using the filename for the alt.

Thus, there is no need to check which element it is -- for all elements, we 
should be using the "alt", "title", "name" and "src" attributes, in that order.

REOPENING.

Troy: I was going to put the "severity" even lower, but I can't, it's already 
at the lowest possible setting... :-)

Comment 4

[troy]

It would have been nice if you had mentioned that subtle change HTML 4.01 
introduced _before_ I went through the trouble to write the code to conform with 
the HTML 4.0 spec. :-)

Comment 5

[Hixie (not reading bugmail)]

Sowwy! :-o

Comment 6

[troy]

Can you point me to the part of the HTNL 4.01 spec that describes the rules to 
use? I didn't see it as clearly defined as it was in the HTML 4.0 spec

I'm only going to change this one more time for version 1.0, and so I want to 
get it right. :-)

Comment 7

[Richard Zach]

I'm putting this in here for the record:

The HTML 4.01 spec no longer includes rules for how to compute missing ALT tags: 

http://www.w3.org/TR/html401/appendix/notes.html#h-B.9

Instead, they refer to the UAAG:

http://www.w3.org/TR/UAAG10/#tech-missing-alt

which in turn suggests looking at the ALTifier tool for "smart techniques
for generating text equivalents for images, etc."  These techniques, however,
are designed for text-based agents, and some of them are not available in the
present situation since here we're talking about cases where Mozilla can't (bad
URL to the image) or won't (image loading turned off) actually load the image. 
In this situation, it is not possible to analyze the image itself to guess a
good alt string (ALTifier suggests looking at the comment string in a GIF, the
size of the image, whether the image is all transparent, etc.).  Nevertheless,
there are some heuristics which could be adapted by Mozilla to provide the best
possible page layout while at the same time including as much informative
content as possible. The following are quoted from the Web Accessibility
Initiative's Evaluation and Repair Interest Group's recommendation on Textual
Equivalents 

[A] http://www.w3.org/WAI/ER/text-equiv.htm

and the ALTifier documentation 

[B] http://www.vorburger.ch/projects/alt/altpaper.html#_Toc443684353.

(0) Return the TITLE, or NAME, or ID of the IMG or, if the IMG is used as link,
the TITLE, NAME, or ID, of the coresponding A. "Sometimes, elements, like IMG or
FRAME, carry a NAME or ID attributes which is a human understandable string,
like "west", "letter", and a tool could come up with an algorithm (sort of the
inverse algorithm used to validate passwd) that would decide it's OK to present
it to a user or in which order to present things (e.g. "#id9808" or
"ASD-987-000X" have low priority)." [A]

(1) For non pure IMG links, that is if there is some text between
the A, IMG and /A tags, return an empty ALT="". The reason for this is
that such an image is likely to be a small inline decoration which,
if it disappears in text browsing, is no loss of information as the existing
link text suffices. [B]

(2) "Set ALT="------" for graphical rulers. A graphical ruler decoration is
identified if height > 1, width / height >= 10, width > 100, height < 50. The
number of '-' characters is approximated dividing the pixel width by 10, but
maximal 65." [B]

(3) "Set ALT="* " for graphical bullets. A graphical bullet decoration is
detected if height > 5, width > 5, width / height <= 4, height < 30, width <
30." [B] 

(4) "Set an empty ALT="" if the IMG is "just" a decorative spacer.  A spacer
is recognized if the image has width or height = 1. [...] The same ALT="" is
applied to images with width or height = 0, as it can occur with special
constructions such as external counter images etc, all of which are certainly of
no interest to text-only agents." [B]

[(2), (3), and (4) of course work only if the IMG tag has WIDTH and HEIGHT
attributes.  In this case, we should render an empty space of specified
dimension.]

(5) "Return the src filename, cut off the path and extension of the
file, replacing '_' and '-' by a blank space. This is based on the
hope that webmasters or graphics designers give meaningful names to their
images, like /images/help.gif (ALT="help") etc." [B]

(6) "Whenever an image used an anchor, or an imagemap, or an frame without label
or an meaningless anchor, one just needs to follow the pointer to the document
on the other side of the HREF to get Metadata about it and present that to the
user so that s/he can decide where to go next. For HTML document, this Metadata
should be the TITLE, either returned as an HTTP header, or as a byte-range on
the HTML source (in the HEAD). For other formats, like image, pdf, Word
document, the tool can determine Metadata in an adhoc fashion: size, type,
name." [A]

Comment 8

[Hixie (not reading bugmail)]

Troy, would you have anything against moving this to M19? Then I could look into
it in late June when I start working on this full time, and get a proper spec
sorted out. At the moment my time is rather limited.

[note to self: see also comments on bug 32351 when dealing with this.]

Comment 9

[troy]

My only objection is that late June is kind of a long time to wait until we 
resolve this issue.

Comment 10

[Kevin McCluskey (gone)]

Reassigning to [e-mail]. Triaging Troy's bug list.

Comment 11

[buster]

redistributing bugs across future milestones, sorry for the spam

Comment 12

[buster]

what we have today is what we're going to ship with unless an outside 
contributor takes ownershipo of this issue very soon.  For now:

This bug has been marked "future" because we have determined that it is not 
critical for netscape6.0. 
If you feel this is an error, or if it blocks your work in some way -- please 
attach your concern to the bug for reconsideration.

Comment 13

[Hixie (not reading bugmail)]

*** This bug has been marked as a duplicate of 41924 ***

Comment 14

[Hixie (not reading bugmail)]

Removing "Future" milestone so it won't appear on my radar...

Comment 15

[John Unruh]

Verified duplicate.