Warns against empty alt attributes for images, but should not

[bortzmeyer]

When there is an empty alternative text (Markdown source) ![]({filename}/images/logo.jpg), Pelican complains "WARNING: Empty alt attribute for image" but it shouldn't:: when the image is not necessary for understanding the page, it is much better to have an empty alternative text.

In this case, if I write ![Logo]({filename}/images/logo.jpg), a screen reader, for instance, will read aloud "Logo", which is useless.

[bortzmeyer]

I must confess that I didn't search if the test is in Pelican or in Python-Markdown. I let better people do the inquiry.

[justinmayer]

I believe this warning provides more value than harm, since it encourages folks who might otherwise omit alternative text to provide it and improve accessibility. That said, there might be a way to address cases in which alternative text is not useful.

What if we used a special indicator, like None, to indicate that there is no useful text to provide?

![None]({filename}/images/logo.jpg)

In the above case, Pelican could suppress the warning. What do you think?

[bortzmeyer]

@justinmayer Adding an useless text decreases accessibiliy (the screen reader reads aloud the useless text). Empty alt attributes are a good thing for accessibility, in the case of useless images.

I suggest to just suppress the warning. An empty ALT is fine for me. https://www.w3.org/TR/WCAG20-TECHS/H67.html https://www.w3.org/WAI/tutorials/images/decorative/

[mosra]

What about making the warning optional under a setting? In my image plugins I have it like that. The user then gets to decide.

[avaris]

We have an option to filter out log messages. Even with an example for this exact case.

[bortzmeyer]

@avaris Great, I missed this option. However, the warning is still spurious.

[justinmayer]

I've already proffered my opinion that I find the warning to have its utility in reminding folks to improve accessibility when they can. As @avaris mentioned, given that there already exists a mechanism by which to filter these warnings, I'm not inclined to take further action on this. That said, I'm not opposed if someone wants to add the functionality I suggested above.

[kernc]

We have an option to filter out log messages. Even with an example for this exact case.

Doesn't work with --fatal warnings. The warning is not printed, but the run still critically fails.

[logological]

I suggest that this issue be reopened.

The problem with the LOG_FILTER workaround described by @avaris and @justinmayer above is that it seems to be an all-or-nothing deal: you either filter out all the alt attribute warnings or none of them. This isn't useful for someone who correctly uses alt attributes (i.e., providing descriptive alt text for images with semantic content, and providing empty alt attributes for purely decorative or redundant images) because disabling the filter will result in spurious warnings about intentionally blank attributes, while enabling the filter will suppress genuine warnings about unintentionally blank attributes. What is really needed to solve this issue is some mechanism to suppress the warnings on a per-image or per-page/per-article basis. One way of doing this would be to allow for log messages to be filtered based on regular expressions, which is something I've raised as Issue #2893.

[logological]

What if we used a special indicator, like None, to indicate that there is no useful text to provide?

![None]({filename}/images/logo.jpg)

In the above case, Pelican could suppress the warning. What do you think?

This might also be a valid solution, but the special indicator needs to be something that would never be found as the genuine value of an alt attribute. None doesn't work because I could well imagine that someone might have an image of the text "None" for which None would be a meaningful and appropriate alt text. (In fact, doing a Google Images search for "none" turns up dozens of such images.)

The solution would also need to be implemented in a such a way that (a) Pelican recognizes this special keyword not just in RST/Markdown pages and articles, but also in HTML templates, (b) Pelican checks for this keyword only after Jinja has substituted all relevant variables, and (c) Pelican removes the special indicator from the HTML output, leaving a genuinely empty alt attribute.

[avaris]

... it seems to be an all-or-nothing deal: you either filter out all the alt attribute warnings or none of them.

Not true. You can filter by exact message, so you can pick and choose which ones are "expected" and list them in the filter.

[logological]

... it seems to be an all-or-nothing deal: you either filter out all the alt attribute warnings or none of them.

Not true. You can filter by exact message, so you can pick and choose which ones are "expected" and list them in the filter.

That's still not particularly convenient. A site might have dozens or even hundreds of images with legitimately empty alt texts, and so manually adding a filter for each of them, and making sure to keep that list in sync with the original images (in case an image is renamed or moved to a different page), is pretty onerous. The problem is even worse for images that appear in widely used templates, since each time a new page or article is created with that template, a corresponding filter for the affected images needs to be added.

It would be better if each affected image could be tagged in a single place (i.e., at the place it's used) and/or if there were some way of tagging multiple images at once (by referring to images by the page/article on which they appear, or by some pattern in their filenames).

[avaris]

This warning only applies to the HTML content of articles or pages. The ones in templates won't trigger it. So that's a non-issue.

Dozens or hundreds of valid alt-less images in page/article source sounds a bit exaggerated to me but sure I'd be willing to accept that. I'm not opposed to a regex solution if someone is willing to implement that.