Page MenuHomePhabricator

Allow editors to provide default alt text on Wikimedia Commons file description pages
Closed, ResolvedPublic

Description

Many Wikimedia images lack alt text, causing accessibility problems. While the ability to provide an alt text in the image thumbnail syntax is valuable, it is unrealistic to expect that it could be used all the time; also there are various ways in which an image can show up without being associated to thumbnail data such as caption and alt text (e.g. on category pages, or the file page itself). There should be a way to provide a default alt text that can be used automatically when there is no better, context-specific alt text (for example in search results, compare T320299: [S] Special:Search images should not have links without alt text for their contents). With Structured Data on Commons available, that would be the obvious option.

(Structured data has the disadvantage that it's only available on fairly complex Wikibase-enabled wiki farms, so there is some value in a different solution that can be used on a vanilla MediaWiki, but that's unlikely to happen soon and as such outside the scope of this task; it's discussed in T21906: Allow default alternate text for images to be provided on the file description page.)

There are three SDC-based approaches:

  • use a dedicated property (which would have to be created on Wikidata first), or
  • use the existing property P2096 (media legend) with an appropriate qualifier (e.g. P3831 (object has role) with the value Q1067764 (alt attribute) or Q60844786 (alt text)). Given how much we expect this information to be used both internally and by external software (which is less prepared to handle qualifier-based intricacies), the dedicated property seems vastly preferable to this.
  • use whatever technology is already being used to provide the multi-lingual "captions" at the top of the "File information" tab of the file description page. This would likely not involve Wikidata at all.

At Wikidata, there have been two property proposals in the past:

  • alt - had some objections about alt text being context-dependent (which per above is not a good reason not to have default alt tags), about alt-text being language-dependent and about the property name. Rejected with "might be relevant to propose it again once structured data is available on Commons".
  • alt tag - largely the same discussion

(There is also has alt-text which sounds similar but was actually intended for describing images not hosted by us.)

The alt text is multilingual so this is blocked by T86517: [Story] Add a new datatype for multilingual text (although Wikidata does allow property proposals for planned item types, they are added to Wikidata:Property proposal/Pending for the time being.


The eventually accepted proposal: P11265 alt text (discussion).

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Note on alt text: This is for the benefit of people using Commons, i.e., when there is no contextual consideration, but where "Painting of X" or "Headshot of Joe Film" might be helpful to sort through images with sometimes unreadable names.

Wikipedia editors might or might not choose to copy the basic alt text, but if they did, they could easily change it whenever "Painting of X" or "Headshot of Joe Film" was not the appropriate description in their context.

The Wikidata "alt" property proposal is stalled, but an "alt" attribute is basically how you would do it. Structured data can handle that. (I don't know if structured data is meant to be included in Wiki* via Lua/magic word or used only on Commons.)

This task is probably a resolved duplicate, I simply don't know where to point it.

Above said, that property proposal is interesting reading, so @Whatamidoing-WMF might consider reviewing it for context.

Tgr renamed this task from Please include suggested alt text for images to Allow editors to provide default alt text on Wikimedia Commons file description pages.EditedJan 5 2020, 3:35 AM
Tgr added a project: Commons.
Tgr updated the task description. (Show Details)
Tgr added a subscriber: Tgr.

Repurposed this to be SDC-specific (for a non-SDC approach there's already T21906: Allow default alternate text for images to be provided on the file description page). The next step would be to write a property proposal (and do it better than the rejected past attempts, which were not very well written).

Currently we use several monolingual text statement for multilingual text data. This is only a workaround.

The Wikidata property proposal was rejected, and for good reason. Please see my comments -and those of others, not least Graham87 - and example image on that page.

Please do not progress this proposal without first consulting with screen reader users and/or accessibility professionals.

Why are we not using the description field for this? Seems more sensible to me than creating new properties

Well, then we need a new field for the caption. They are not meant to solve the same problem and should almost always be different from each other. So for every image it would be very useful with two separate text fields.

Well, then we need a new field for the caption. They are not meant to solve the same problem and should almost always be different from each other. So for every image it would be very useful with two separate text fields.

No we don't, captions are just labels, see https://commons.wikimedia.org/wiki/Special:EntityData/M96527.json . Description is currently unused in SDOC.

We're thinking of organizing a workshop on this topic, with accessibility consultants, people with lived experience, the WikiBlind user group, and anyone else who is interested. Does that seem like a useful way to explore these questions?

No we don't, captions are just labels, see https://commons.wikimedia.org/wiki/Special:EntityData/M96527.json . Description is currently unused in SDOC.

Well, perhaps the variable is called label in the code, but in the Wikipedia app, people are being asked to fill these fields as image captions. So it's a bit of a conflicting usage of that specific field right now (descriptions on Commons, captions in the Wikipedia app), but neither of them are for the purpose of alt text. Which means it would be a huge work cleaning up before it would be useable even if we started to designate that field for it. Better start fresh in my opinion (and if the label/description/caption field is redundant in your opinion, then suggest remove it in a separate ticket).

No we don't, captions are just labels, see https://commons.wikimedia.org/wiki/Special:EntityData/M96527.json . Description is currently unused in SDOC.

Well, perhaps the variable is called label in the code, but in the Wikipedia app, people are being asked to fill these fields as image captions. So it's a bit of a conflicting usage of that specific field right now (descriptions on Commons, captions in the Wikipedia app), but neither of them are for the purpose of alt text. Which means it would be a huge work cleaning up before it would be useable even if we started to designate that field for it. Better start fresh in my opinion (and if the label/description/caption field is redundant in your opinion, then suggest remove it in a separate ticket).

You don't understand. The description array is empty for *every* file on Commons. It's not used at all. So if we technically need a place to store this in a multilingual way, it's still available (fresh in your words). In the user interface you can call it whatever you like.

You don't understand. The description array is empty for *every* file on Commons. It's not used at all. So if we technically need a place to store this in a multilingual way, it's still available (fresh in your words). In the user interface you can call it whatever you like.

You are correct, I mixed it up. And now that I do understand, I agree with you that this could be a possible solution.

Not a great solution though - it would be pretty confusing to have a description structured data field and a description template field, with completely different semantics. The obvious role for the description field would be to be a plaintext equivalent of the description in the info template.

From my perspective, there could be more than one alt-text per image and language in the SDC data. It would then be up to consumers to select which alt-text they would like to use.

We're thinking of organizing a workshop on this topic, with accessibility consultants, people with lived experience, the WikiBlind user group, and anyone else who is interested. Does that seem like a useful way to explore these questions?

@Ainali Thats sounds great :) .

Village pump proposal now archived here: https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2022/05#Adding_alt_texts_through_structured_data

The proposal was not quite as clear as it could have been, which probably cost some votes, but I think that's a pretty positive response over all.

I think that's a pretty positive response over all.

There were several significant, detailed objections, which were not refuted. It was not a vote.

SUPPORT

Request for temporary workaround.

I have been asked to add alt text as for an article I nominated as "good" on English Wikipedia.

Whilst we are waiting for this is there any workaround? For example is there an easy way I can find out whether an image already has alt-text written for it somewhere? As I am a native speaker of English I can write the alt text without much difficulty - but many editors on English Wikipedia are not native speakers so it can be hard for them to write alt text.

There were several significant, detailed objections, which were not refuted.

When I wrote "positive response" I meant that people at Commons in principle think that it would be a good idea to provide alt texts in one way or another.

Afaict, there were 3 objections:

  1. "Alt text is context dependent" - that shouldn't keep us from offering general purpose default alt texts like "a basket full of mushrooms on a wooden table" that can be overridden with existing syntax: [[File:foo.jpg|thumb|description|alt=specific alt text]]. No counterarguments have been made against this.
  2. "Alt text is language dependent" - so what, that's not an argument against providing alt text. That's an argument for making sure it is provided in a multi-lingual manner.
  3. there were concerns about the best way to implement the whole thing. These were beside the point of the proposal at Commons. I don't think anybody disagreed that is should be done via SDC in one way or another. Whether that's best done through a new property, something akin to the already existing multi-lingual "captions" or something else is not really something the Commons community can decide.

So what exactly are we arguing about here?

El_Grafo updated the task description. (Show Details)
  1. "Alt text is context dependent" - that shouldn't keep us from offering general purpose default alt texts like "a basket full of mushrooms on a wooden table" that can be overridden with existing syntax: [[File:foo.jpg|thumb|description|alt=specific alt text]]. No counterarguments have been made against this.

If the image is used on the article about the species of fungus, would that be good alt text? No.

Would it used, to tick a box? Yes.

So what exactly are we arguing about here?

Some people think doing the above is acceptable, because their level of concern only amounts to ticking boxes.

Some of us - including those who actually use assistive software due to blindness - are arguing against doing such harm.

I have been asked to add alt text as for an article I nominated as "good" on English Wikipedia.

...is there an easy way I can find out whether an image already has alt-text written for it somewhere?

If you want the article to be badged as "good article" then default alt text will not be suitable. Its images need text alternatives that are specific to the context in which the image is used on that particular article and which take into account the content of their captions.

The parenthetical part of this extract from the task description:

There should be a way to provide a default alt text that can be used automatically when there is no better, context-specific alt text (for example in search results, compare T320299).

was recently added. This is erroneous logic.

The better solution would be for SDC captions to be shown in the search results.

  1. "Alt text is context dependent" - that shouldn't keep us from offering general purpose default alt texts like "a basket full of mushrooms on a wooden table" that can be overridden with existing syntax: [[File:foo.jpg|thumb|description|alt=specific alt text]]. No counterarguments have been made against this.

If the image is used on the article about the species of fungus, would that be good alt text? No.

Surely, it is still better than no alt text?
What I see here is perfect being the enemy of good. With no other offered solution, I think we should accept that there is no perfect solution and start with something, because even if it just provides value in half of the cases, it is still an enormous improvement of the current situation.

  1. "Alt text is context dependent" - that shouldn't keep us from offering general purpose default alt texts like "a basket full of mushrooms on a wooden table" that can be overridden with existing syntax: [[File:foo.jpg|thumb|description|alt=specific alt text]]. No counterarguments have been made against this.

If the image is used on the article about the species of fungus, would that be good alt text? No.

Surely, it is still better than no alt text?

No.

Why would you think it is?

With no other offered solution

Solution to what?

Why is the status quo - alt text is added manually, in situ, when and where required - not a solution?

I have some other points that should be taken into consideration

  1. Having a default alt tag, will increase the size of an img transclusion on pages, which seems something to keep an eye on.
  2. Review... In much the same way as default content from wikidata was a problem for en.wp, I suspect that default content for alt tags from Commons might be a problem for that community. It would be the first text content from Commons that by default becomes part of wp articles, sourced by search engines etc. There is a vandalism angle possible there, and they may argue that Commons' review processes are not setup to detect that, so that might become a conflict point.
  3. Per the law of levels of investment required to get something useful... This is likely only to benefit en.wp in any sort of substantial level. Other languages will stil mostly be left out.
  4. It could be a distinguishing feature to have multi lingual alt text of very popular media items.
  1. "Alt text is context dependent" - that shouldn't keep us from offering general purpose default alt texts like "a basket full of mushrooms on a wooden table" that can be overridden with existing syntax: [[File:foo.jpg|thumb|description|alt=specific alt text]]. No counterarguments have been made against this.

If the image is used on the article about the species of fungus, would that be good alt text? No.

Then the it could still be overridden by a better one that fits the fungus species article better. You keep ignoring that.

Some of us - including those who actually use assistive software due to blindness - are arguing against doing such harm.

I'm happy to admit that I have zero background with this kind of thing. If it is actually doing harm, then we shouldn't do it. But currently, it's only you arguing against this, so I'm having difficulties assessing whether that's the generally accepted stance of a larger community of people or just your own opinion. We've had a poll among the Commons community, how do we get a representative opinion of those people who actually use alt texts?

I have some other points that should be taken into consideration

  1. Having a default alt tag, will increase the size of an img transclusion on pages, which seems something to keep an eye on.
  2. Review... In much the same way as default content from wikidata was a problem for en.wp, I suspect that default content for alt tags from Commons might be a problem for that community. It would be the first text content from Commons that by default becomes part of wp articles, sourced by search engines etc. There is a vandalism angle possible there, and they may argue that Commons' review processes are not setup to detect that, so that might become a conflict point.
  3. Per the law of levels of investment required to get something useful... This is likely only to benefit en.wp in any sort of substantial level. Other languages will stil mostly be left out.
  4. It could be a distinguishing feature to have multi lingual alt text of very popular media items.
  1. is an important point. But this task here is about being able to offer alt texts on Commons. That's certainly not something to force down anyone's throat. Whether or not individual wikis actually want to use them, would be a decision best left up to them. And that decision should be made long after the community at Commons has had a chance to actually add some alt texts and figure out how to handle the system.
  2. Yes, most texts would probably be in English, but that doesn't mean that only en.wikipedia would benefit (if they chose to use it). I'm sure other English language projects like en.wikivoyage could benefit just as well. Could use them on Commons itself, pipe them through InstantCommons, offer them to search engines, ...
  1. "Alt text is context dependent" - that shouldn't keep us from offering general purpose default alt texts like "a basket full of mushrooms on a wooden table" that can be overridden with existing syntax: [[File:foo.jpg|thumb|description|alt=specific alt text]]. No counterarguments have been made against this.

If the image is used on the article about the species of fungus, would that be good alt text? No.

Then the it could still be overridden by a better one that fits the fungus species article better. You keep ignoring that.

Far from ignoring it; I have given it great consideration, and come to the conclusion that the possibility does not mitigate the issue I describe.

Furthermore, instead of accessibility tools alerting editors to the missing alt text, they will be falsely assured that the matter has been dealt with.

Some of us - including those who actually use assistive software due to blindness - are arguing against doing such harm.

I'm happy to admit that I have zero background with this kind of thing.

And yet you do not accept the conclusions of those of us who do

If it is actually doing harm, then we shouldn't do it. But currently, it's only you arguing against this,

No, it is not.

so I'm having difficulties assessing whether that's the generally accepted stance of a larger community of people or just your own opinion.

As I noted above, objectors include "those who actually use assistive software due to blindness"

I have some other points that should be taken into consideration

  1. Review... In much the same way as default content from wikidata was a problem for en.wp, I suspect that default content for alt tags from Commons might be a problem for that community. It would be the first text content from Commons that by default becomes part of wp articles, sourced by search engines etc. There is a vandalism angle possible there, and they may argue that Commons' review processes are not setup to detect that, so that might become a conflict point.
  2. Per the law of levels of investment required to get something useful... This is likely only to benefit en.wp in any sort of substantial level. Other languages will stil mostly be left out.
  3. It could be a distinguishing feature to have multi lingual alt text of very popular media items.

Regarding 2. and 3. I think like in the case of Wikidata, the most value will be for other wikis than enwiki. So let's make this an opt-in feature and enwiki can vote no as usual for having it implemented there. Important cross-wiki features like this should not be blocked by just one language version being opposed to it.
Regarding 4. There is a 'mul' tag on its way for labels and descriptions (T285156).

Tgr claimed this task.

The Wikidata property proposal was accepted: P11265 (alt text). Note that pending T86517: [Story] Add a new datatype for multilingual text it is monolingual text, not multilingual text; as mentioned above, the standard workaround is to have multiple monolingual claims instead of one multilingual claim.

As noted above, the Commons community already supports structured alt text, but since the Wikidata property proposal took such a long time, I have left a new notice: Commons:Village pump#Alt text for Commons images as structured data.

With that, I think this task is resolved (although some of the comments still hold valuable insights and concerns, and we should find the right place for those); I will file new tasks for making use of the data.

Hi Gergö,

thank you very much! A very important step towards accessibilty.

Happy Holidays:-)

Karsten

Am 26.12.22 um 01:02 schrieb Tgr:

View Task https://phabricator.wikimedia.org/T166094
Tgr closed this task as "Resolved".
Tgr claimed this task.
Tgr added a comment.

The Wikidata property proposal was accepted: P11265 (alt text)
https://www.wikidata.org/wiki/Property:P11265. Note that pending
T86517: [Story] Add a new datatype for multilingual text
https://phabricator.wikimedia.org/T86517 it is monolingual text, not
multilingual text; as mentioned above, the standard workaround is to
have multiple monolingual claims instead of one multilingual claim.

As noted above, the Commons community already supports
https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2022/05#Adding_alt_texts_through_structured_data
structured alt text, but since the Wikidata property proposal took
such a long time, I have left a new notice: Commons:Village pump#Alt
text for Commons images as structured data
https://commons.wikimedia.org/wiki/Commons:Village_pump#Alt_text_for_Commons_images_as_structured_data.

With that, I think this task is resolved (although some of the
comments still hold valuable insights and concerns, and we should find
the right place for those); I will file new tasks for making use of
the data.

*TASK DETAIL*
https://phabricator.wikimedia.org/T166094

*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/

*To: *Tgr
*Cc: *TheDJ, Chidgk1, El_Grafo, Metamorforme42, SyntaxTerror, Nikki,
DrMel, Sdkb, Base, FRomeo_WMF, Multichill, CBogen, Conny, putnik,
KH32, Ainali, Michael, Abbe98, Pigsonthewing, Bugreporter, Tgr,
Dvorapa, thiemowmde, Lydia_Pintscher, Izno, Whatamidoing-WMF,
Aklapper, Astuthiodit_1, karapayneWMDE, bwang, Invadibot, Mooeena,
GFontenelle_WMF, maantietaja, Y.ssk, Muchiri124, ItamarWMDE,
Nintendofan885, Akuckartz, Nandana, JKSTNK, Lahi, Gq86, E1presidente,
Ramsey-WMF, Cparle, SandraF_WMF, GoranSMilovanovic, QZanden,
Orienteerix, Tramullas, Acer, LawExplorer, Flycatchr, Salgo60, Zppix,
Silverfish, _jensen, rosalieper, Taiwania_Justo, Scott_WUaS,
Susannaanas, Volker_E, Ixocactus, Wong128hk, Fuzheado, Jane023,
Wikidata-bugs, matthiasmullie, aude, Daniel_Mietchen, Dinoguy1000,
Ricordisamoa, Wesalius, Raymond, Steinsplitter, Mbch331, Jay8g