Closed Bug 24125 Opened 20 years ago Closed 20 years ago
Support the 'name' attribute in the alt text generation algorithm
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.
Stealing QA contact. Lowering priority. Moving out to M18. Adding dependency on 1994 and from 7954.
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
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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... :-)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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. :-)
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. :-)
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]
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.]
My only objection is that late June is kind of a long time to wait until we resolve this issue.
Reassigning to email@example.com. Triaging Troy's bug list.
Assignee: troy → buster
Status: REOPENED → NEW
redistributing bugs across future milestones, sorry for the spam
Target Milestone: M18 → M19
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.
Target Milestone: M19 → Future
*** This bug has been marked as a duplicate of 41924 ***
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → DUPLICATE
Removing "Future" milestone so it won't appear on my radar...
Target Milestone: Future → ---
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.