Wikimedia Bugzilla is closed!

Sorry, the last paragraph is redundant...

To be more specific, the application's behaviour will change as follows:
- The link's title attribute will remain unchanged (for tooltips)
- The image's alt attribute will contain the text "tooltip-ca-nstab-media" by default
- Depending on the existence of a caption text the file name will be added to the alt attribute. If there is a caption available, the file name won't be added.
- The zoom icon's alt attribute doesn't have an alt attribute at all.

The changes only affect images that are being embedded using one of the values stored in key "img_thumbnail" (i. e. thumbnail, thumb) in the MessagesXx.php files.

You're modifying the parser.  Could you add some parser tests for this and make sure the current parser tests continue to work?

Do I understand correctly, that the zoom icon will be 'silent'/ignored after this change ?

Have we considered the effect on elements such as video and audio fragments that are also inserted here ?

Be really careful here btw, this whole alt attributes thing was one of the most ridiculously over debated changes over the past years.

For instance people were vehemently against providing default alt texts, because "people won't ever bother writing a proper one". I guess that's where quality meets usage once more :D

"In the upload dialogue for the graphics provide help/explanations for the authors of the respective articles."

Case in point, our images are used in multiple places, which is why we don't have centralized captions and alt tags. http://en.wikipedia.org/wiki/Wikipedia:Alternative_text_for_images#Importance_of_context

No in that case, it would have to be part of the 'insert image' dialog in the toolbar for instance.

Also relates to bug 24586

Kai, thanks again for the patch.  Could you move it into Gerrit?

Done:
https://gerrit.wikimedia.org/r/#/c/9967/

I also fit the expected results in parserTests.txt to the new markup.

Left a message at https://en.wikipedia.org/wiki/Wikipedia_talk:Alternative_text_for_images#Changes_in_thumbnail_alt_text

to give the community opportunity to comment.

And informed the project https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Accessibility#Changes_in_thumbnail_alt_text

I've gone ahead and notified http://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Accessibility for added measure.

As a screen reader user, I support this solution; it sounds like the most sensible one, seeing as almost every image description page must be linked for licensing purposes.

I endorse Graham's comments and I've commented at http://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Accessibility#Changes_in_thumbnail_alt_text

In essence, this is an improvement, although I'm always sceptical about the value of putting image filenames into alt text. That's a recipe for annoying screen reader users - but obviously better than nothing.

Has anyone tested this on IE 6, 7 or 8 ? We are repositioning the magnify icon, and it's probably wise to check wether this still works on those browsers.

We should probably also announce this, because there might be several scripts and styling rules on various wiki's depending on the old DOM structure for thumbnails.

The ogghandler extension is not compatible with this patch. See review comments.

I'm from the accessibility project, just like Rex Schneider and Graham87.

This is an improvement indeed. However, please never use file name in the alt text. I mean never. Several file name might be descriptive, but in a great many cases they are not. We cannot rely on it. In a screen reader, "File:ECARmulticolor4.tnl.jpg" would be read aloud "ECARmulticolorfour dot tnl dot jpg". It is useless and confusing.

The responsibility to write captions and meaningful alt text falls on the editors, the software cannot do it for them.

On the other hand, the the alt text cannot be empty when the image is part of a link. Thus, if there is no alt text and no caption, stick to the default alt text "view the media page" only. It will do the job well enough. 

Thanks for your accessibility improvement Kai Nissen. Thanks Derk-Jan Hartman for asking our opinions on the matter.

(In reply to comment #15)
> I'm from the accessibility project, just like Rex Schneider and Graham87.
> 
> This is an improvement indeed. However, please never use file name in the alt
> text. I mean never. Several file name might be descriptive, but in a great many
> cases they are not. We cannot rely on it. In a screen reader,
> "File:ECARmulticolor4.tnl.jpg" would be read aloud "ECARmulticolorfour dot tnl
> dot jpg". It is useless and confusing.
> 
> The responsibility to write captions and meaningful alt text falls on the
> editors, the software cannot do it for them.
> 
> On the other hand, the the alt text cannot be empty when the image is part of a
> link. Thus, if there is no alt text and no caption, stick to the default alt
> text "view the media page" only. It will do the job well enough. 
> 
> Thanks for your accessibility improvement Kai Nissen. Thanks Derk-Jan Hartman
> for asking our opinions on the matter.

Would it make sense to combine the two choices and say: 'View the media page of ECARmulticolor4.tnl.jpg' in the case of alt text not being specified? (I've never used a screen reader, I'm wondering from a prespective of would it be confusing to have 'View media page' 20 odd times in a page with no way of distinguishing which media page the prompt is for).

(In reply to comment #16)
> Would it make sense to combine the two choices and say: 'View the media page of
> ECARmulticolor4.tnl.jpg' in the case of alt text not being specified?

"ECARmulticolor4.tnl.jpg" really does not make any sense when heard in a screen reader. It's like random characters "fsldjn%ç*"akj".

> (I've never used a screen reader, I'm wondering from a prespective of would it be
> confusing to have 'View media page' 20 odd times in a page with no way of
> distinguishing which media page the prompt is for).

Good thinking. It seems to be an issue to consider. Maybe we could number the instances where there is no caption and no specific alt text. Thus, we could add a number after the default alt text "view the media page". The result could be like "view the media page number 1", "view the media page number 2"...

Hmm, I wonder how common it is for file names to be unintelligable. On todays featured article, it would appear out of 17 images, 14 have intelligable names (and the other 3 would if people used spaces instead of CamelCase). But the situation is probably worse on less well developed articles.

(In reply to comment #18)
> Hmm, I wonder how common it is for file names to be unintelligible.

There are far greater issues than this. What about other languages?
1) The main problem is that the file name is not international. It is mostly in English. A German blind user at the German Wikipedia is going to get an English alt text. And on top of that, its screen reader will think it is German, and will read it as such. Horrible result.

2) Several files are written in random foreign language. German, French, Spanish... Even Chinese and Russian. Examples :
*File:Fotothek df ps 0004293 Wohnhäuser ^ Wandgestaltungen - Wandverkleidungen.jpg
*File:漓江山水.jpg
*File:Саратовский техникум промышленных технологий и автомобильного сервиса.jpg

I hope theses two major points bring an end to this discussion. No file name in alt text, please. :-)

This issue is currently stalled in gerrit because the patch requires changes in mediahandler extensions that are not part of core, notably OggHandler, which is a Wikipedia deployed extension (and probably also TimedMediaHandler, and many other JS based media handlers).

Change 9967 abandoned by Hashar:
(bug 34750) Accessibility improvement for embedded images

Reason:
Until the issues in media handlers have been dealt with, there is no point in keeping this change open.   Follow up on bug report :)

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