Last modified: 2014-11-19 10:21:58 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36750, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34750 - Accessibility for embedded images
Accessibility for embedded images
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.18.x
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: accessibility, parser
Depends on:
Blocks: 367 24584
  Show dependency treegraph
 
Reported: 2012-02-27 12:16 UTC by Kai Nissen
Modified: 2014-11-19 10:21 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
patch for better accessibility of embedded images (3.33 KB, patch)
2012-02-27 12:16 UTC, Kai Nissen
Details

Description Kai Nissen 2012-02-27 12:16:48 UTC
Created attachment 10113 [details]
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.
Comment 1 Kai Nissen 2012-02-27 16:10:11 UTC
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.
Comment 2 Mark A. Hershberger 2012-02-27 18:06:05 UTC
You're modifying the parser.  Could you add some parser tests for this and make sure the current parser tests continue to work?
Comment 3 Derk-Jan Hartman 2012-02-27 20:41:44 UTC
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 ?
Comment 4 Derk-Jan Hartman 2012-02-27 21:02:48 UTC
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
Comment 5 Derk-Jan Hartman 2012-02-27 21:15:01 UTC
"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.
Comment 6 Derk-Jan Hartman 2012-02-27 23:13:33 UTC
Also relates to bug 24586
Comment 7 Sumana Harihareswara 2012-05-25 02:29:34 UTC
Kai, thanks again for the patch.  Could you move it into Gerrit?
Comment 8 Kai Nissen 2012-06-04 10:10:10 UTC
Done:
https://gerrit.wikimedia.org/r/#/c/9967/

I also fit the expected results in parserTests.txt to the new markup.
Comment 9 Derk-Jan Hartman 2012-07-03 07:56:32 UTC
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.
Comment 11 Graham87 2012-07-03 15:56:36 UTC
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.
Comment 12 Rex Schneider 2012-07-04 00:42:19 UTC
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.
Comment 13 Derk-Jan Hartman 2012-07-04 18:42:37 UTC
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.
Comment 14 Derk-Jan Hartman 2012-07-04 18:50:41 UTC
The ogghandler extension is not compatible with this patch. See review comments.
Comment 15 Rodan BURY 2012-07-06 12:46:16 UTC
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.
Comment 16 Bawolff (Brian Wolff) 2012-07-06 13:04:29 UTC
(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).
Comment 17 Rodan BURY 2012-07-06 13:45:58 UTC
(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"...
Comment 18 Bawolff (Brian Wolff) 2012-07-06 14:11:27 UTC
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.
Comment 19 Rodan BURY 2012-07-06 20:57:07 UTC
(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. :-)
Comment 20 Derk-Jan Hartman 2012-07-31 21:46:18 UTC
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).
Comment 21 Gerrit Notification Bot 2013-09-29 13:35:42 UTC
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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links