Talk:Wikimedia Apps/Team/Android/Image Recommendations

alt= texts are not a good idea for LINT errors and not for newbies in Growth

To make a textual description of meaningful illustrations a very high level of skills is required by users:

• You need an advanced understanding what blind people or others shall take from a textual or audible image description if they shall really benefit.
• If you clutter many images with not helpful but time consuming bad whaffle-whaffle then blind people and others will switch off image descriptions or stop opening descriptions.
• All image descriptions must be an added value to the textual content of the page. If a significant rate is bad then it is waste of time to try whether this particular image description might be the one good among hundred bad stories.
• To create a good image description will take five or ten minutes and needs a longer literaric process.

First precondition for asking people in the field is to teach them how to do that, and to provide good guidance.

• If people are not educated they will create alt texts which are confusing and just stealing time.
• An operational guidance, a cookbook is to be provided first, before pushing people to write alt= texts.
• In English, some good help is available by associations outside WMF, but I am not aware of any wiki page which is breeding alt= text editors.
• In German, the external sites did not establish user guidance yet. Some first steps were made, but not sufficient. German Wikipedia is attempting to develop an operational manual, currently on user page level.
• A common understanding of a reasonable image description is needed. Some people are telling that they should not exceed 100 letters, but this is nonsense. To represent the major aspects of an image in certain context, easily 1000 or 2000 characters are needed.
• First thing to learn is that it is a very bad idea to just copy the regular image legend as alt= text. The legend is told always, and if the same wording is repeated as alt= text then you hear the same stuff twice and have no added value.
• Second thing is that there are many images which are only decorative, only eye-catchers and duplicating the same textual information which is already present in current context. The same information as the textual “yes” is visually condensed as “green tic hook”. The existence of such enforcing visualizations must not be mentioned in such places. The COA or a flag of a country may visually help to identify cities and countries, but they are pointless in addition to the textual name of this place which is told anyway. The biggest mistake would be to start explaining the details of the Stars And Stripes by number and colour of stripes and number of white stars and blue background in which corner if the following text is simply “USA”.
• Third thing is that there are many many images, which are nice visual illustrations, but impossible to describe by text. Think of organic molecules in chemistry, or impression of a caribean beach or a nice lake in the forrest. All that beaches are looking the same, nice. There is a blue lake at good wheather between two trees and in the background some hills. So what?

LINT errors are the wrong tool for improving accessibility.

• A LINT error will take a few seconds to add a missing ' or delete a superfluous HTML tag. Many people are able to perform this task.
• An image description in current context might require ten minutes each.
• There are millions of images without alt= in a wiki. Nobody will be able to go through LINT categories and create good and helpful descriptions for all of them.
• Millions of LINT errors will stay for decades in statistics. German Wikipedia reached zero level last fall, currently permitting LINT errors at user pages to avoid conflicts. If you add ten million errors nobody will be able to help them, and the only effect is frustration.

PerfektesChaos (talk) 10:08, 27 February 2024 (UTC)

Hello @PerfektesChaos,

Appreciate your detailed feedback and comments. You said some really good comments about the high-level goal, which should be passed on and considered for planning, and interface design for any task feature.

As a reply to your points in the Lint error final section, our soft ware engineers are responding that we need to know more about the actual workflow involved to know if this is an actual problem to actual tools people are using though; to imply an "inbox zero" quick-n-easy-tasks intention for lints, on the theory that missing alt text, while easy to detect, is hard to fix.

And the mention of the LINT errors in the German Wikipedia; It's unclear if this describes an actual workflow problem. It's expected - so far as the Content Transform expressed - that linter error matches may stay around in large numbers for a long time, and this would not imply any problem. We need to clarify whether this "inbox zero" impulse is a real thing here to consider, and if so how to address it.

ARamadan-WMF (talk) 11:29, 29 February 2024 (UTC)

The actual workflow in German Wikipedia is to reach or keep zero errors in LINT statistics.

• If you add 10 millions of missing alt= this would frustrate the maintenance crew, and real LINT errors would be drowning in a flood of alt= messages, also on each page info list.
• There is a general workflow rule in German Wikipedia: Only errors which can be remedied are permitted to be listed in maintenance categories or by any error message.
• Missing alt= will stay for decades, but nobody will be able to fix them. Each one will require ten minutes or more to create a story matching the reason of this illustration in current context.
• A kind of poetry is necessary: If you close your eyes, then only hearing the description, the image must appear inside your head. When opening the eyes, the same image shall be visible on the screen. That’s no business for everybody. If no similar image appeared within your mind, the description is waste of time.

There is no staff to add this for millions of images.

• This is definitely no task for newcomers.
• Even experienced article authors need special training to create meaningful image descriptions in addition and without intersection compared to legend=caption text, or suppress the entire image where not adding value.
• We learnt that almost all article authors are creating contra-productive alt= if they are asked to equip images, and they made the situation worse.
• This is no “quick-n-easy-task” and therefore no issue for Growth nor LINT.

Greetings --PerfektesChaos (talk) 14:26, 7 March 2024 (UTC)

alt vs captions and multiple use cases

I think one element that requires additional attention in a flow like this, are the fact that we in many cases already provide captions. While captions might not be a full replacement for the alt value, they DO already provide a lot of contextual information about an image to those who need it. It is important that an alt provides additive value to the caption and that we help and educate users on how to write a proper alt text. A bad alt + caption might be worse than no alt + caption. For that reason, the flow for alt's of thumbnails and the flow for alts of inline images (without captions) might have to be slightly different. Additionally, we have to consider that many image uses might be made through a template. The template might have its own |alt parameter, or it might provide the entire alt text. This is something that the recommendation engine has to take into account, because they can be totally different workflows for modifying them. They might even require different linting categories because they are so different. Concepts that authors should know are: decorative use, context of the image use, describing the image vs captioning the image. —TheDJ (Not WMF) (talk • contribs) 11:04, 27 February 2024 (UTC)

Hello @TheDJ,

It's nice to find a comment from you to something related to the apps!

Thank you for your good point for the high-level feature goal; we will work on giving good guidance to users on how alt text and captions differ, and how they sometimes only exist in one form or the other depending on if an image is a thumbnail or inline.

And image uses made through a template is a true fact and this is another advantage to using the linter, it already specifies whether it's in a template invocation. This should allow us to exclude such matches if we're uncertain how to express them in the source.

Your explanation for the concepts that authors should know is a good high-level feature feedback; thank you for that! ARamadan-WMF (talk) 11:42, 29 February 2024 (UTC)