114531 - alt="" inserted when user enters no text

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[Ben Bucksch (:BenB)]

Reproduction:
1. Insert Image in Composer
2. Select Image (file, URL)
3. Hit OK
4. Confirm warning box about no alt text
5. Do not enter alt text, instead do nothing
6. Hit OK
7. Look at HTML source

Actual result:
alt="" is inserted into the img tag

Expected result:
Either user is force to enter alt text or (IMO better) no alt at all is inserted.

Rationale:
While I do like the fact that we have a warning box, I don't think users will
understand the consequence of not adding alt text.

alt="" means that text-only UAs should not render it, i.e. it is irrelevant to
the content and just visual fluff. If the user manually inserted an image, that
is almost never true. Thus adding alt="" automatically causes dataloss for users
of plaintext UAs. alt="" does *not* mean "I don't know what to put there".

I think, we should provide an extra checkbox like "This image is not important
for the content", which disables the alt textfield in the dialog and inserts
alt="" in the doc.

Anyways, being syntactically wrong (no alt attribute at all) is IMO better than
being semantically wrong (claiming the image were not important while it in fact
is).

Comment 1

[Ben Bucksch (:BenB)]

For more discussion, see bug 114287.

Comment 2

[Ben Bucksch (:BenB)]

FYI: I'm not really sure what the best solution is (maybe one not listed in
"Expected results"). We should /not/, however, add some dummy text - the WAI
explicitly recommends against that.

Comment 3

[Kevin McCluskey (gone)]

Reassigning to Editor:Composer component

Comment 4

[Kathleen :Brade]

I think this bug should be resolved as INVALID since we don't want to create
invalid html documents (and we have prompted the user to enter alt text).

Also, not adding alt="" would mean that the user has no way to say "this image
is meaningless and should have alt=""

People who really don't want alt="" in their html can use another editor to
remove this attribute.

Comment 5

[sujay]

verified.

Comment 6

[Ben Bucksch (:BenB)]

This bug is a prefectly valid suggestion. Reopening.

> I think this bug should be resolved as INVALID since we don't want to create
> invalid html documents (and we have prompted the user to enter alt text).

Then *force* the user to either enter something or check the checkbox 'meaningless'.

> Also, not adding alt="" would mean that the user has no way to say "this image
> is meaningless and should have alt=""

Please read the original description.

> People who really don't want alt="" in their html can use another editor to
> remove this attribute.

This bug is not about the people using the editor, but having to read its output
(e.g. in plaintext).

Comment 7

[Charles Manske]

While I agree with brade's arguments, I am willing to consider adding a 
checkbox, now that the image dialog is smaller. We get enough complaints about
the warning dialog behavior that being able to consciously check it is 
probably better UI than having the warning dialog popup every time.
Suggested behavior:
1. Checkbox is checked when editing props for existing images that have alt="". 
It's unchecked when inserting new images.
2. After 'Ok', warning dialog popups up if checkbox is unchecked and alt field 
is empty. Dialog text should be appended to say something like "Check the 
checkbox to indicate that this image is not important and should not have alt 
text." 
Robin: Any suggestions for the Checkbox text and new sentence in the warning
dialog?

Comment 8

[robinf]

I'll take a stab at this. How about using radio buttons instead, which for me
seems clearer than using a checkbox:

* Use alternative text: _______
* Don't use alternative text

If first radio button is chosen, but user leave out the alt text, they see the
alt text alert dialog when they click OK in the Image Prop dialog. To this alert
dialog,  we append the text "If you don't want to include alternative text,
select the option "Don't use alternative text."

Comment 9

[rubydoo123]

I would scream loudly if the end result is a document with a 4.0/4.01 doctype 
with missing required attriubtes. Regardless if the user wants to insert a text 
string for the alt attribute or not, on export the alt attribute must be 
present, even if it is empty.

Comment 10

[Charles Manske]

Beppe: Don't worry! Either use must enter some text, or we will write 
alt=""
if the "Don't use" option is checked.
If all we do is offer "use" vs. "don't use", then the simplest UI would be one 
checkbox:
[ ] Alternative text: ___________________________

Unchecking the checkbox means "I don't want it"

Comment 11

[Ben Bucksch (:BenB)]

> the simplest UI would be one checkbox:
> [ ] Alternative text: ___________________________
> Unchecking the checkbox means "I don't want it"

This doesn't make clear what unchecking the checkbox does. It makes it look like
alt text were something optional, while it is not.

I like Robin's suggestion better. But his wording also doesn't make clear what
alt="" does (which is the reason why I filed this bug in the first place). When
we insert alt="", the user must be aware that what(ever) he did means that the
image might not be present in some versions of the output and/or he must confirm
that the image is irrelevant to the content. E.g. (taking Robin's suggestion):
* Alternative Text [________________]
o This image is irrelevant to the content of the document
(Textbox is disabled, if the 2. option is chosen.)

Comment 12

[Kathleen :Brade]

The radio button option Robin presented is much clearer than the checkbox option
 in comment 10.

For the 2nd radio button, how about something like:
 o  No alternate text is appropriate

Comment 13

[Kathleen :Brade]

collision!
I agree with Ben, the edit field should be disabled (and empty) if the user
clicks the 2nd radio button choice.

Comment 14

[Charles Manske]

Ok, I will implement the radio button feature. How about this:
() Alternate text: _________________________________
() Alternate text is not appropriate for this image

The following is is copied from W3C and I thought it was useful background 
info (we should probably use similar description in our help text):

While alternate text may be very helpful, it must be handled with care. Authors
should observe the following guidelines:

    * Do not specify irrelevant alternate text when including images intended to
format a page, for instance, alt="red ball" would be inappropriate for an image
that adds a red ball for decorating a heading or paragraph. In such cases, the
alternate text should be the empty string (""). Authors are in any case advised
to avoid using images to format pages; style sheets should be used instead.
    * Do not specify meaningless alternate text (e.g., "dummy text"). Not only
will this frustrate users, it will slow down user agents that must convert text
to speech or braille output.

Comment 15

[Ben Bucksch (:BenB)]

> () Alternate text is not appropriate for this image

This leaves the user at guessing that "appropriate" is.

[HTML4 spec quote]

"This image is irrelevant to the content of the document" says just that, not?

Warning dialog:
The current text of the warning dialog is:
"It is recommended that you supply alternate text that will appear in text-only
browsers, and that will appear in other browsers when an image is loading or
when image loading is disabled."
If this bug is implemented, I suggest the following wording:
"If the image is relevant to the content of the document, you have to supply
alternate text that will appear in text-only browsers, and that will appear in
other browsers when an image is loading or when image loading is disabled."
(or s/have to/must/)
I think that the first part of the sentence is similar enough to the suggested
wording of the option box so that the user can find it himself, without us
having to hint him that he can check it.
The dialog should IMO then *always* (not only once) come up when the user
checked "Alternate text", but entered none.

Comment 16

[robinf]

For the second radio button, I don't think users will know what we mean if we
say "Alternate text is not appropriate" or "Alternate text is not relevant".
That's why I prefer "Don't use alternate text" for the second radio button.

Comment 17

[Charles Manske]

I've implemented the radio buttons in my tree and I do like the new behavior and
dialog layout, so we just have to decide on text for the 2nd radio button and 
error dialog. I currently use "Alternate text is not appropriate for this image".
The dialog always comes up if "Alternate text" is checked. If 2nd radio is
checked, we always write out 'alt=""'. Initial radio checked is the 2nd if
that is found for an exisiting image, avoiding the warning dialog for that image.

Robin: What do you think about the Ben's warning dialog text?
("If the image is relevant to the content of the document, you have to supply
alternate text that will appear in text-only browsers, and that will appear in
other browsers when an image is loading or when image loading is disabled.")
Could we use that, but us "Don't use alternate text" for the radio button text?

Comment 18

[robinf]

Ben's warning dialog text is fine, except I'd like to change "have to" to "must": 
"If the image is relevant to the content of the document, you must supply
alternate text that will appear in text-only browsers, and that will appear in
other browsers when an image is loading or when image loading is disabled."

Yes, I think "Don't use alternate text" would work for the 2nd radio button.

Comment 19

[Charles Manske]

Attachment: Add radio buttons to control Alt text usage

Comment 20

[Charles Manske]

Attachment: Updated patch to handle radio button states when inserting new image

Comment 21

[Charles Manske]

Per review from brade, I added comments to explain new alt text behavior:
/*
 Note: We encourage non-empty alt text for images inserted into a page. 
 When there's no alt text, we always write 'alt=""' as the attribute, since
"alt" is a required attribute.
 We allow users to not have alt text by checking a "Don't use alterate text"
radio button,
 and we don't accept spaces as valid alt text. A space used to be required to
avoid the error message
 if user didn't enter alt text, but is uneccessary now that we no longer annoy
the user 
 with the error dialog if alt="" is present on an img element.
 We trim all spaces at the beginning and end of user's alt text
*/

I also replace "0" and "1" with "false" and "true" for params in 
SetAltTextRadio().

Comment 22

[Kathleen :Brade]

I'd like to see this line in the xul changed to explicitly pass null in:
  oninput = "SetAltTextRadio();"

and this line in the JS corrected (checkbox-->radio button):
+  // Force user to enter Alt text only if checkbox is checked

r=brade

Comment 23

[Charles Manske]

Attachment: Updated patch to address all issues by reviews

Comment 24

[kinmoz]

Comment on attachment 66216 [details] [diff] [review]
Updated patch to address all issues by reviews

sr=[e-mail]

Can we rename that 'x' variable to something meaningful?

Comment 25

[Charles Manske]

checked in

Comment 26

[michael wendell]

Verified on trunk build 2002012503.

Comment 27

[Henrik Gemal]

this is not fixed. If you check the "dont use alt text" and insert a image
alt="" is inserted...

Comment 28

[Kathleen :Brade]

From Ben's original description:
I think, we should provide an extra checkbox like "This image is not important
for the content", which disables the alt textfield in the dialog and inserts
alt="" in the doc.

I believe this is what we decided on so I am re-resolving this bug.

Composer documents should always be valid so we have to emit the alt tag (even
if it is empty).

Comment 29

[Ben Bucksch (:BenB)]

I agree that this is fixed (apart from the wording of the checkbox maybe, but no
reason to reopen).
Remarking as Verify.