1743591 - "you must supply alternate text" when adding a border to inline image

Status: UNCONFIRMED

(MailNews Core :: Composition, defect)

Description

[Ray]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

attempted to add single pixel border to inline image (image dropped into body of email on "attach inline" side of pane)

Actual results:

When I clicked OK, this error popped up...

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

Expected results:

a single pixel border should have been applied and then allowed me to move on. I do not want to add alt text - it has no relevance, my email is private and NOT a web page. As it is I can not add a border without adding alt text.

Comment 1

[Henry Wilkes (they/them) [:henry-x]]

When an image is added by drag and drop, its element is <img src="..." /> with no alt attribute.

But if you use the image dialog, which is also used for editing (as in this case), it will not close unless the user sets the alt attribute with the "Alternate text" input or selects "Don't use alternate text" in the "Location" tab.

I don't think it's bad to remind users to choose alt text because it's a general courtesy to include alt text. It is very circumstantial to know that you could not include it.

In any case, the current approach can be improved. First of all, "Don't use alternate text" is a bit misleading because it currently sets the alt explicitly to "", which treats the image as decorative. If the image is not purely decorative, this can be worse than setting no alt text because it would hide it from screen readers. So this option should probably be split into something like "Image does not need alternate text" (alt="") and "Don't provide alternate text".

Also, the warning dialog is confusing: the wording is geared towards web pages instead of email, and it takes you back to the image dialog without directing you to the alternate text section. So we should either:

• Mark the "Alternate Text" input as required, and use notifications within the dialog to explain it.
• Or, the warning dialog should also have the different alternative text options within it so the user can select what to do without having to return to the image dialog.

I'm not sure what to do about the alt text of inline images added through drag and drop though. Maybe we should prompt the user after the drop with a dialog to set it.

NOTE: If the user sets the "Tooltip", then it can act as the accessible name in place of alt text. If this is an appropriate accessible name, then the alt attribute should be left out and not set to "" nor the same value as the tooltip. In firefox, the alt="" is ignored when the title is given (bug 1700174) but this is not the same in other browsers. This is a bit finicky, so I'm not sure what would be the best way to direct the user towards the correct approach.

Comment 2

[Alessandro Castellani [:aleca]]

I'm not sure what to do about the alt text of inline images added through drag and drop though. Maybe we should prompt the user after the drop with a dialog to set it.

For this, we could potentially consider 2 approaches:

• Add the image with a default alt="" attribute, and therefore having the Don't use alternate text checked by default.
• Add the image with a the alt attribute pre-filled with the filename.

The second approach would potentially solve the problem for users that want to style the image after it has been added, but using the filename is not really correct and in most cases useless.

We have bug 1731213, which was originally created as a meta bug to track the effort of dropping all these dialogs and offer more dynamic solutions for these sort of edits (doorhangers, html5 dialogs).

In general, this dialog is very outdated and should be heavily restructured.

Any other possible ideas?

Comment 3

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Alessandro Castellani [:aleca] from comment #2)

I'm not sure what to do about the alt text of inline images added through drag and drop though. Maybe we should prompt the user after the drop with a dialog to set it.

For this, we could potentially consider 2 approaches:

• Add the image with a default alt="" attribute, and therefore having the Don't use alternate text checked by default.

I would avoid setting alt="" unless it is explicitly selected by the user. Otherwise we're completely hiding it by default from screen readers. I feel like a receiver would rather know about bad or missing alt text, which they could respond to with a request for clarification, rather than never know about a potentially relevant image.

• Add the image with a the alt attribute pre-filled with the filename.
  The second approach would potentially solve the problem for users that want to style the image after it has been added, but using the filename is not really correct and in most cases useless.

If the user does not provide an explicit alt text, then no alt might be better. I don't know if we can make up for the user, and the receiver's screen reader might handle it better than we could.

@aleca, do you know what your screen reader does when it encounters an image in an email with missing alt text? Looking online, it seems they tend to read the filename, but I'm not sure what gets used when the src is not a file path (inline images use the content-id cid: scheme), or whether users can configure the alt-text behaviour (e.g. get an explicit "missing alternate text" announcement).

Comment 4

[Henry Wilkes (they/them) [:henry-x]]

(In reply to Henry Wilkes [:henry] from comment #3)

@aleca, do you know what your screen reader does when it encounters an image in an email with missing alt text? Looking online, it seems they tend to read the filename, but I'm not sure what gets used when the src is not a file path (inline images use the content-id cid: scheme), or whether users can configure the alt-text behaviour (e.g. get an explicit "missing alternate text" announcement).

Comment 5

[Alessandro Castellani [:aleca]]

So, it seems that the behaviour changes based on the screen reader.

The default Windows reader (Narrator), simply reads "Message body, Image selected".
If I add an alt attribute, I get "Message body, Image 'reads-alt-text' selected".

JAWS is a bit more throughout and reads the full file path, but if there's an alt, it reads that.

With both screen readers ignore it if the alt attribute is present but empty, fall backing to the default behaviour.