Closed Bug 172253 Opened 22 years ago Closed 22 years ago

RFE: put image alt text in status bar

Categories

(SeaMonkey :: General, enhancement)

Product:
SeaMonkey
Component:
General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED INVALID

People

(Reporter: aaronlev, Assigned: asa)

Details

(Whiteboard: INVALID)

Since bug 25537 is not going to be fixed (show alt text in tooltips), it makes it hard to check the alt text on a web page, or see what it is. I don't think properties is a convenient enough a place. Therefore, I think we should show alt text for images in the status bar. When a user mouses over an image with alt text, or focuses a linked image with alt text, it would be nice if the status bar showed the alt text, after the URL. http://www.mozilla.org Description: none or http://www.google.com Description: "Google"
Alternate text isn't a description. Alternate text is an _alternative_ to the image. If the image is available, the alt text is redundant. If the image isn't available, the alt text is visible. If a page is misusing alt texts then file a tech evang bug. If we are incorrectly not showing alt texts when we should, file a layout bug. But there is no reason to show alternate text when the image _is_ available. INVALID.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Whiteboard: INVALID
20 different china pages want this...
Bug 74241 is a better compramise see that bug
Verified.
Status: RESOLVED → VERIFIED
Ian, I have a problem with the quick way you marked this invalid without allowing a discussion. You say the alt text is a redundant replacement for the image. By it's very nature, text is not redundant with an image, because they're in a different medium. They're 2 different methods used to describe something, and sometimes one way supplements the other. That's like saying an English translation of a Chinese restaurant menu is redundant, so just leave it out. They're equivalent replacements, but sometimes people use both at the same time. Having no feedback makes it very hard for people to get feedback on the accessibility of their pages in Mozilla. Instead of saying "Description" in the status bar we could say "Text:" of that better matches the meaning ascribed to ALT.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
aaron: the correct fix is to get load images (prior versions of netscape had a load images menuitem/button) to work (correctly would be nice), then people could load (perhaps even unload) images and quickly see whether their page is accessible.
Why is that the "correct" fix?
The correct fix is bug 101910.
This is invalid for _exactly_ the same reason as the alt-text-as-tooltip bug. It doesn't matter _where_ the text is displayed, if it is easily accessible then people will treat it as the way to show _descriptive_ or _additional_ information, which is exactly the opposite of what alt text should be. > You say the alt text is a redundant replacement for the image. By it's very > nature, text is not redundant with an image, because they're in a different > medium. If there is alt text that is not redundant, then the page is wrong (technically in fact the page is invalid) and that should be a tech evang bug. The whole _point_ of alternate text is that it be redundant. > That's like saying an English translation of a Chinese restaurant menu is > redundant, so just leave it out. They're equivalent replacements, but > sometimes people use both at the same time. No, it's like saying that the laminated version of the menu is redundant with the paper version. They convey exactly the same information. Sometimes you want one, sometimes you want the other. You never need both. > Having no feedback makes it very hard for people to get feedback on the > accessibility of their pages in Mozilla. To get feedback on whether their page is readable without images, they should _turn images off_. We already support that. (If there are bugs with it, then please file separate bugs.) There are even extensions that can be installed which provide one-button access to toggling images. BTW: Discussion is allowed, of course; the bug doesn't have to be left open for it to continue. However, I would guess that every possible angle for this discussion has already been examined in detail in bug 25547.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
QA Contact: asa → ian
Resolution: --- → INVALID
I insist on a discussion before you just close it out. What's wrong with that? Does your knowledge of standards cover UAAG? The current UAAG working draft Item 2a allows rendering of the conditional content C (e.g. alternative, description, ...) in addition to the piece of content D. 2.3 Render conditional content. (P1) Techniques for checkpoint 2.3 1. Allow configuration to provide access to each piece of unrendered conditional content "C". 2. When a specification does not explain how to provide access to this content, do so as follows: * If C is a summary, title, alternative, description, or expansion of another piece of content D, provide access through at least one of the following mechanisms: o (1a) render C in place of D; o (2a) render C in addition to D; o (3a) provide access to C by allowing the user to query D. In this case, the user agent must also alert the user, on a per-element basis, to the existence of C (so that the user knows to query D); o (4a) allow the user to follow a link to C from the context of D.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → INVALID
This is practically a duplicate of bug 25537, so discussion is also duplicated. The arguments are the same regardless of where ALT text appears. "The alt attribute specifies alternate text that is rendered when the image cannot be displayed". Similarly, we don't show tooltips or status bar messages for alternate content in OBJECTs when the original content can be displayed. For alternate content we already follow quoted UUAG recommendation 1a: "render C in place of D". -> INVALID
Correction on "The arguments are the same regardless of where ALT text appears". That's too general. I meant to say that arguments are the same regardless of where ALT text is proposed to appear on mouseover. Of course, ALT text should appear as alternate content and there is a valid argument for it being listed in the Image Properties.
VERIFIED. The point is that if we render alternate text on mouseover then we are giving the signal to authors that alt="" means "additional information"; if we do it in the status bar we're basically saying "alt means status, title means tooltip". We know that this is the case because that is _exactly_ what happened when Nav and IE used alt for tooltips: authors got the message that alt was for tooltips. So far there have been no valid reasons why we should do this. Accessibility is not such a reason, since we already follow the UAAG in this respect, and are in fact actively trying to promote the WCAG by not showing alternate content on mouseover. You also did not respond to any of my previous points explaining why this is a bad idea.
Status: RESOLVED → VERIFIED
Calm down Aaron see comment 3
The href attribute of the a tag does not mean 'status' either, it means destination. This clearly means that mozilla currently displays all pages incorrectly. How is this different to alt? The status panel has clearly already been redefined as an area for useful information and not just status messages. The alt property is now viewable if you right click and select properties. This was clearly included for a reason. The difference between a right click then left click and a hover is only one of convenience. I am one of the people that would find an easy and quick display of the alt text extremely useful. For reasons that I do not wish to disclose I often find it hard to interpret the meaning of an image given on a page. I do not have that much of a problem that I want to turn images off altogether, so I turn to reading the alternative text. I do not want to find a description of the image or extra information for a link that would be correctly included within a TITLE attribute. What I want is to read the alternative text, which by definition portrays the same meaning as the image. To have this as a two click process for every image on a page makes navigating this way extremely hard. I believe it to be an accessibility issue that this information is not readily available and makes mozilla an unlikely choice for anyone with similar problems.
Tim, As an extension to mozilla, or just for yourself, it's not especially hard to write an XBL binding for images that will display the ALT text wherever you want -- as a tooltip, as text underneath the image, probably in the status bar, or as floating text. That way, mozilla itself doesn't have to keep adding prefs to suit people who want "specialty" behaviors.
> How is this different to alt? Displaying the alt text encourages bad authoring practices. That's why we don't want to show it anywhere (except inline, if the image is missing).
Having a pref so that those users who NEED this feature can enable it clearly does not encourage bad authoring because the standard behaviour is NOT to display it. If you think excluding one single pref checkbox is more important that having a browser that is accessible to everyone then just say so.
[UAAG] > * If C is a summary, title, alternative, description, or expansion of > another piece of content D, provide access through at least one of the > following mechanisms: [comment #11] > For alternate content we already follow quoted UUAG recommendation 1a: > "render C in place of D". clearly you have C (ALT text) and D (the image) mixed up.
I don't think so... Why do you say that?
because when mozilla finds and image D and an alt text C it loads the image D and not the alt text C , the opposite of C in place of D. when images are turned off is the only time this behavoir is used. With images on i believe the behaviour to currently be: o (4a) allow the user to follow a link to C from the context of D.
No, it's the other way around. That is the whole point of alternate text. It is ALTERNATE. Either we show the image, or ALTERNATIVELY we show the ALTERNATE text.
What I said was an accurate interpretation of the UAAG and mozilla implementation of. In that recommendation there are options to Display the Alt instead of the Image, Display the Alt AND the Image, Provide access to the Alt through a query of the image (with indication of the existance of alt), Provide access to the Alt through the context of the Image. Whichever one you are in favour of, and whether you care about the UAAG or not, that is what the UAAG says on the subject. comment 19 was right in pointing out that comment 11 was wrong, the current behaviour is not to render the alt in place of the image! However as I pointed out Mozilla does satisfy the last option 4(a).
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.