One user at the English WP discussion noted that they were not a fan of the inclusion of the link as it caused misclicks to the image description rather than the intended result which is the page for the search result.

I don't know if that preferences a lean toward one or the other of the two actions. "Consistency" with how mobile/Vector22 provide a link might be relevant. Either way, it might inspire a slightly different modification from item two, pointing instead to the search result instead of the image description page (adding appropriate alt text to that version).

One issue to consider: If the link is suppressed there should be another way to indicate attribution, as required by copyleft licenses.

I just detected this task, but have created T320344 already. There is a slighly different approach, but basically duplicated.

The alternative solution is to equip elements with

class="noviewer" aria-hidden="true" role="presentation"

If a screenreader is telling the page content such eye catchers are not mentioned. Otherwise blind people will be bothered with all the URL as image description, which is pointless.

@PerfektesChaos Why would aria-hidden="true" and role="presentation" be added? As soon as former is there, it's taken out of accessibility tree anyways.

In T320299#8303473, @Volker_E wrote:

@PerfektesChaos Why would aria-hidden="true" and role="presentation" be added? As soon as former is there, it's taken out of accessibility tree anyways.

Depends on screenreader software.

Many blind user never change their screenreader they are used to, since it is very difficult to learn modified features and new or other interfaces.

Looking at current standard and most recent implementations, yes, should work.

However, aria-hidden="true" and role="presentation" are already redundant, but of different age. And they express the same as alt="" but the idea is that if the recipient does not understand one of these messages any of the other two communicates the same: Suppress. Therefore these are three ways to express the same, and the hope is that at least one of them is caught. Such is called defensive programming.

We will be removing the alt text property from these thumbnails since they are decorative and context can be gained from the search result itself. Additionally there is no consensus on how to provide alt text. There are many existing tickets trying to tackle this problem including T166094. If a solution is found, we can revisit adding alt text to the search result thumbnails.

In T320299#8308516, @CBogen wrote:

We will be removing the alt text property from these thumbnails since they are decorative and context can be gained from the search result itself. Additionally there is no consensus on how to provide alt text. There are many existing tickets trying to tackle this problem including T166094. If a solution is found, we can revisit adding alt text to the search result thumbnails.

These already have their alt property removed. The issue is that there is a link that surrounds the image that points to a place but that place is not adequately described for a screen reader (because there is no alt text). I'm sorry if my suggested DOM made it non-obvious what the intent of option 1 above was: remove the <a>.

In T320299#8308630, @Izno wrote:

In T320299#8308516, @CBogen wrote:

We will be removing the alt text property from these thumbnails since they are decorative and context can be gained from the search result itself. Additionally there is no consensus on how to provide alt text. There are many existing tickets trying to tackle this problem including T166094. If a solution is found, we can revisit adding alt text to the search result thumbnails.

These already have their alt property removed. The issue is that there is a link that surrounds the image that points to a place but that place is not adequately described for a screen reader (because there is no alt text). I'm sorry if my suggested DOM made it non-obvious what the intent of option 1 above was: remove the <a>.

Got it. Updated, thanks!

I misunderstood. Removing the <a> means removing the link to the image, which is potentially problematic. Instead we'd like to add alt text for the thumbnails that reads "image for PAGENAME" so that screen readers understand the purpose of the image and the link. Please let us know if you have any concerns with this approach.

In T320299#8311943, @CBogen wrote:

I misunderstood. Removing the <a> means removing the link to the image, which is potentially problematic. Instead we'd like to add alt text for the thumbnails that reads "image for PAGENAME" so that screen readers understand the purpose of the image and the link. Please let us know if you have any concerns with this approach.

That seems fine.

I understand the reticence for FILE namespace searches, but I think something can still be done here. It's still the page image for the page image returned. Maybe something like "file description page for PAGENAME".

I'd also recommend having a different alt for placeholder images.

There is no alt text required for screnreaders.

Blind people shall never experience that there is any eye-catcher for improved visual experience.

• They shall not learn that there is any image at all.
• This information is absolutely pointless.
• The existence of the image is to be suppressed.
• There are three ways to attribute that, and since you never know which language is understood usually all three are fired:
  • alt=""
  • aria-hidden="true"
  • role="presentation"

Thanks for pointing out on defensive programming.
From my perspective empty alt="" (1) is most important here, as it's most widely supported, actually universally supported in browsers AFAIO.
aria-hidden="true" (2) is additional safety net and maybe also a signal to debugging devs to clarify it was a planned decision to keep alt empty.

Given that we also need to think from front-end performance angle, I don't see added value in additionally add role="presentation" – as the need is already covered by adding 1 and 2.

My understanding is that we need to have alt text in order to keep the link, otherwise the link will not make sense to screenreaders.

Also note that not only blind people use screen readers. Some may have significantly impaired vision, but still be able to make out that something is there on the screen. More context in the form of alt text might be of use. Especially since the thumbnail is not purely decorational - it's also wrapped within a link to the file, one that loses meaning if we hide the thumbnail's existence from screen readers.

IMO, there is no "perfect" solution here, and I think we should err on the side of potentially giving some users too much information rather than others potentially not enough.
Those for who the information isn't relevant can chose to ignore it (much how I tend to visually ignore other information overload; e.g. the size & date metadata below search results is usually of little use for most of my searches)

Note: "image for PAGENAME" only really works for the article-namespace thumbnails; "file description page for PAGENAME" also feels a bit odd to describe an image.
How do we feel about simply describing all cases as "thumbnail for PAGENAME" (where pagename could be either article, or file, depending on the namespace)? Feels like an accurate description (with the added benefit of being consistent throughout)?

As for the placeholder; that one *is* purely decorational, perhaps aria-hidden="true" makes most sense here?

In T320299#8312668, @CBogen wrote:

My understanding is that we need to have alt text in order to keep the link, otherwise the link will not make sense to screenreaders.

I'm convinced there's no added value to screenreader users for the link right now. If the path is chosen, aria-hidden goes onto the whole link clearly.

<a href="..." class="image" aria-hidden="true">
    <img src="..." data-and-otherthings="..." alt="">
</a>

Currently, the only information about the link is the file name read out. @matthiasmullie was already pointing this out. As there's no guidance around naming files and no automatism around making them human friendly when uploaded to Commons, screenreader user find themself ending up with

“link, File:US_Navy_051203-N-2383B-223_U.S._Naval_Academy_Midshipman_fullback_Adam_Ballard_(22)_rushes_for_one_of_two_touchdowns_while_being_persued_by_Army_defenders_Cason_Shrode_(54)_and_Taylor_Justice_(42).jpg”

read out on the search term football.

That's just noise.

Another topic, not yet in the task description, the .searchResultImage-thumbnail-placeholder should also feature aria-hidden for path above.

In T320299#8314763, @Volker_E wrote:

I'm convinced there's no added value to screenreader users for the link right now. If the path is chosen, aria-hidden goes onto the whole link clearly.

<a href="..." class="image" aria-hidden="true">
    <img src="..." data-and-otherthings="..." alt="">
</a>

AIUI, aria-hidden is not to be used on focusable elements (per MDN docs), so can't go on the link (or at least should be expected to behave unpredictably)

Change 842701 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[mediawiki/core@master] Add alt text for thumbnails, aria-hidden for placeholder

https://gerrit.wikimedia.org/r/842701

I have a patch ready that will:

• add aria-hidden to placeholder
• add "thumbnail for PAGENAME" alt text for thumbnails for all namespaces (main + file)

Thoughts? Any issues with that?

add aria-hidden to placeholder
add "thumbnail for PAGENAME" alt text for thumbnails

This is pointless. The entire parent element is to be suppressed for screenreaders.

Blind people, or aural only audience, never learn that the answering page does contain any visual preview of the search results. They get text only, as until September 2022, and shall not get confused by telling them that there are additional hints which they can neither hear nor see. Therefore they never reach the image, and they do not need to get any alt="explanation" but might get a declaration as not useful image alt="" for all in case the other suppression mechanism failed.

Your message is telling that here is an image which you cannot see at all and if you could see it you cannot see anything since no page image is present. Such nonsense is to be suppressed.

The alt= is usually evaluated only by screenreaders, which is a non-visual environment. It is an informative description of the content of an important, non-decorative illustration written in the language of the listener.

For technical reasons, e.g. as a placeholder during slow loading, title="logo" may be used. That shows up in page if no images shall be presented for this user, or the graphics are still transferred via slow connection. That may be one of two words (not wider than the thumbnail) title="preview" or title="placeholder". Note that these are repeating and not very informative, and not L10N yet.

BTW, PAGENAME is written already in the textual result just next to the image. Do not repeat yourself.

In T320299#8312643, @Volker_E wrote:

Given that we also need to think from front-end performance angle, I don't see added value in additionally add role="presentation" – as the need is already covered by adding 1 and 2.

You are expecting that every screen reader is compliant to the most recent standard.

• They are not.
• Blind people are reluctant to modify their software.
• If something fails, they are not only blind but also deaf and mute.
• Never change a running system.
• They cannot see any popup window during installation. They cannot configure any installation option of a screenreader since they need a screenreader for understanding the manual, the installation dialog, and all local documents on the machine and the system interface.
• They get the screenreader installed when they get the hardware, and it runs as long as the hardware works.
• It is not easy to learn how this software is controlled. Those persons are afraid that anything in usage will change with a new version since they are trained how to use their system, and they have admirable skills on the screenreader they are adapted to. This software is a key issue to connect them to the world, the e-mail and chats, the internet.
• Please switch off your screen now, then answer this post with keyboard only and do not forget to send the post via [Tab] navigation on submit button. So you might get an impression how computer usage without eyes and ears works.

Since you do not know which client software will understand which syntax, it is common practice to trigger all three suppression mechanisms simultaneously in redundant mode, and at least one of them will succeed:

• alt=""
• aria-hidden="true"
• role="presentation"

In T320299#8318544, @PerfektesChaos wrote:

In T320299#8312643, @Volker_E wrote:

Given that we also need to think from front-end performance angle, I don't see added value in additionally add role="presentation" – as the need is already covered by adding 1 and 2.

Since you do not know which client software will understand which syntax, it is common practice to trigger all three suppression mechanisms simultaneously in redundant mode, and at least one of them will succeed:

• alt=""
• aria-hidden="true"
• role="presentation"

I hear you. But please take into account, that role="presentation" is the least supported addition from all three. We can easily assume that empty alt, which is part of HTML since 1.2 and required attribute since HTML 4.01 will not fail any (more modern) browser and assistive technology software, as they would have to have taken away support for the first two in order to make role required.

In T320299#8316218, @matthiasmullie wrote:

In T320299#8314763, @Volker_E wrote:

I'm convinced there's no added value to screenreader users for the link right now. If the path is chosen, aria-hidden goes onto the whole link clearly.

<a href="..." class="image" aria-hidden="true">
    <img src="..." data-and-otherthings="..." alt="">
</a>

AIUI, aria-hidden is not to be used on focusable elements (per MDN docs), so can't go on the link (or at least should be expected to behave unpredictably)

You're right. The additional piece here is to decide

• if keyboard users should proceed to access the thumbnail link (probably yes, a product decision that would maybe benefit from a tooltip on focus); that would mean to add aria-hidden one DOM level up
• or if that link is a GUI/pointer&touch only feature, then adding `tabindex="-1" would be the way to go.

In T320299#8318831, @Volker_E wrote:

In T320299#8316218, @matthiasmullie wrote:

In T320299#8314763, @Volker_E wrote:

I'm convinced there's no added value to screenreader users for the link right now. If the path is chosen, aria-hidden goes onto the whole link clearly.

<a href="..." class="image" aria-hidden="true">
    <img src="..." data-and-otherthings="..." alt="">
</a>

AIUI, aria-hidden is not to be used on focusable elements (per MDN docs), so can't go on the link (or at least should be expected to behave unpredictably)

You're right. The additional piece here is to decide

• if keyboard users should proceed to access the thumbnail link (probably yes, a product decision that would maybe benefit from a tooltip on focus); that would mean to add aria-hidden one DOM level up

Per MDN, adding aria-hidden one level up is also a faux-pas:

aria-hidden="true" should not be used on elements that can receive focus. Additionally, since this attribute is inherited by an element's children, it should not be added onto the parent or ancestor of a focusable element.

In T320299#8318489, @PerfektesChaos wrote:

add aria-hidden to placeholder
add "thumbnail for PAGENAME" alt text for thumbnails

This is pointless. The entire parent element is to be suppressed for screenreaders.

I agree that taking the link out for screen readers would probably be the ideal solution. After all, it is likely of little/no use for them to be alerted to purely visual content (although note that not all screen reader users are completely blind - some may still see that something is there and attempt to reach it)
However, AFAIK, there is no way to actually do that other than removing the actual link, for everyone.

Since we can't (at least not reliably) hide the link from screen readers (except with negative tab index, which destroys keyboard navigation for everyone), we should thus expect screen readers to visit the link. When they do, they currently find a link with unknown content: there is an image with an empty alt attribute.
IMO, the best thing we can do is to add an as-informative-as-possible alt text so they at least know what it's about (and know that they can ignore it)
Repeating the PAGENAME is not an issue IMO: in the likely case that the link is of no use to them, they can skip as soon as they hear their assistive tool announce "thumb..."

I guess we could still try to add aria-hidden="true" instructions to the link and some screen readers might follow them regardless, but we should expect that this will not be the case for all.
I'm not sure what my opinion about this is - on the one hand, it's explicitly documented not to be supported and as such may have unexpected behavior across platforms; on the other hand, that unsupported behavior would probably be the preferred one.
@Volker_E - what's your opinion on this?

No activity in a week - any opposition to move forward with the proposed solution?

In T320299#8338548, @matthiasmullie wrote:

No activity in a week - any opposition to move forward with the proposed solution?

Strong oppose

• No blind user shall ever learn that there are any images in this region.
• Therefore no alt= is needed for anything.
• This entire task is completely nonsense.
• No patch is needed for anything.
• It is pointless to tell people who cannot see images that here is a placeholder image since no preview image is available.
• Even for the article image the description is the textual search result. For those who need alt= it gives no additional information, even more if not told in their own human language.

This entire task is completely nonsense.

Hmm? You can argue about which of the two implementations should be preferred, but the task itself is quite valid.

It is pointless to add an English image description Placeholder, we have no preview image here which will be forwarded only to people with screenreaders, which is an aural non-visual presentation of the content, and where the existence of any image is to be hidden from the recipients at all to avoid confusion.

Therfore the entire transferring of alt=Nonsense is just a waste of bandwith, since all the images are to be suppressed from screenreaders, therefore no screenreader ever can tell the alt text of a non-existing image. And nobody else will receive an alt text.

@PerfektesChaos The alt text is not about placeholders, but about the actual images (if they exist)
Those images are wrapped within a link (which can't be aria-hidden) so screen readers may stumble upon them.
We're adding an alt text so that, even though it likely is not useful for them, at least they know the contents within that link.

The placeholders are separate. They're not an issue. They aren't wrapped within a links & are purely decorational. They will be aria-hidden & we will not add alt text to the placeholders.

Change 842701 merged by jenkins-bot:

[mediawiki/core@master] Add alt text for thumbnails, aria-hidden for placeholder

https://gerrit.wikimedia.org/r/842701

Testing notes for verifying after deployment: Checked in the current production (wmf.14) and compared with what was added in betalabs. VoiceOver (MacOS) with Safari 15.6 was used.

enwiki betalabs	enwiki wmf.14
<a href="/wiki/Cat" title="Cat"><img alt="Thumbnail for Cat" src="https://upload.wikimedia.org/wikipedia/commons/thumb/0/0b/Cat_poster_1.jpg/150px-Cat_poster_1.jpg" decoding="async" data-file-width="5935" data-file-height="3898" width="150" height="99"></a>	<a href="/wiki/Football" title="Football"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/a/ad/Football_in_Bloomington%2C_Indiana%2C_1996.jpg/150px-Football_in_Bloomington%2C_Indiana%2C_1996.jpg" decoding="async" data-file-width="3420" data-file-height="2328" width="150" height="102"></a>
focus on a thumbnail image - the thumbnail for Cat is mentioned	focus on a thumbnail image - the thumbnail is not mentioned
cannot focus on a placeholder img: <div class="searchResultImage-thumbnail-placeholder" aria-hidden="true">	cannot focus on a placeholder img :<div class="searchResultImage-thumbnail-placeholder">