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).

For more discussion, see bug 114287.

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.

Reassigning to Editor:Composer component

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.

verified.

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).

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?

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."

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.

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"

> 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.)

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

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

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.

> () 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.

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.

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?

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.

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().

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 on attachment 66216 [details] [diff] [review] Updated patch to address all issues by reviews sr=kin@netscape.com Can we rename that 'x' variable to something meaningful?

checked in

Verified on trunk build 2002012503.

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

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).

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