Page MenuHomePhabricator

Allow editors to provide default alt text on Wikimedia Commons file description pages
Open, MediumPublic

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. 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 two SDC-based approaches:

  • use a dedicated property (which would have to be created first), or
  • use 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.

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.

Related Objects

Event Timeline

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