Accessibility for embedded images
OpenPublic

Description

patch for better accessibility of embedded images

According to the accessibility report (http://www.thirdageonline.eu/project-tao-2/software-development/mediawiki-accessibility-enhancements/) the thumbnail images on article pages are not being built properly.

This is mentioned in paragraph 1.1.1 as problem 2 and 3. I propose the attached patch to set a describing "View the media page" (tooltip-ca-nstab-media in MessagesXx.php) as the alternative text and to integrate all elements leading to the file description page into just one link.

The attached patch will make MediaWiki set a default text as the alternative (alt) attribute ('tooltip-ca-nstab-media' from MessagesXx.php). If there is no caption text set to describe the image, it sets the images' file name as a descriptive text. It also puts the thumb image and the zoom icon into one link.


Version: 1.18.x
Severity: normal

Attached: thumbnailer-patch.diff

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz34750.
kai.nissen created this task.Via LegacyFeb 27 2012, 12:16 PM
kai.nissen added a comment.Via ConduitFeb 27 2012, 4:10 PM

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.

MarkAHershberger added a comment.Via ConduitFeb 27 2012, 6:06 PM

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

TheDJ added a comment.Via ConduitFeb 27 2012, 8:41 PM

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 ?

TheDJ added a comment.Via ConduitFeb 27 2012, 9:02 PM

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

TheDJ added a comment.Via ConduitFeb 27 2012, 9:15 PM

"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.

TheDJ added a comment.Via ConduitFeb 27 2012, 11:13 PM

Also relates to bug 24586

bzimport added a comment.Via ConduitMay 25 2012, 2:29 AM

sumanah wrote:

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

kai.nissen added a comment.Via ConduitJun 4 2012, 10:10 AM

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

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

TheDJ added a comment.Via ConduitJul 3 2012, 7:56 AM
Graham87 added a comment.Via ConduitJul 3 2012, 3:56 PM

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.

bzimport added a comment.Via ConduitJul 4 2012, 12:42 AM

rexs wrote:

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.

TheDJ added a comment.Via ConduitJul 4 2012, 6:42 PM

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.

TheDJ added a comment.Via ConduitJul 4 2012, 6:50 PM

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

bzimport added a comment.Via ConduitJul 6 2012, 12:46 PM

bury.rodan wrote:

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.

Bawolff added a comment.Via ConduitJul 6 2012, 1:04 PM

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

bzimport added a comment.Via ConduitJul 6 2012, 1:45 PM

bury.rodan wrote:

(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"...

Bawolff added a comment.Via ConduitJul 6 2012, 2:11 PM

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.

bzimport added a comment.Via ConduitJul 6 2012, 8:57 PM

bury.rodan wrote:

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

TheDJ added a comment.Via ConduitJul 31 2012, 9:46 PM

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

gerritbot added a comment.Via ConduitSep 29 2013, 1:35 PM

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

Liuxinyu970226 removed a subscriber: Liuxinyu970226.Via WebNov 24 2014, 4:46 AM
Gilles added a project: Multimedia.Via WebNov 24 2014, 3:11 PM
Liuxinyu970226 removed a subscriber: Liuxinyu970226.Via WebNov 27 2014, 2:12 AM
MarkAHershberger removed a subscriber: MarkAHershberger.Via EmailMar 8 2015, 10:14 AM

Add Comment