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.