maria.schiewe wrote:

Please note: Because images are always surrounded by links they either need and alternative text or another text also included in the link. If neither of this is true, the screenreader will read the URL of the images to give the user some indication what kind of link this is, else the output would onyl be “link” which won’t be of any use. Please see Techniques for WCAG 2.0: [http://www.w3.org/TR/WCAG20-TECHS/F89.html F89: Failure of 2.4.4, 2.4.9 and 4.1.2 due to using null alt on an image where the image is the only content in a link].

Ok, so cases:

[[File:image|alt=|link=|caption]]

Thumb

• normal link target
  • default: empty <img> alt attribute, requires <a> title attribute ("Description page of Filename" ????)
  • alt= explicitly sets an alt text
• (explicit link target is not possible/allowed in thumbs currently. Bug 17398)

Framed

• normal link target
  • default: <img> alt attribute is the caption, <a> title attribute ("Description page of Filename" ????)
  • alt= explicitly set an alt text (possibly empty value)
• (explicit link target is not possible/allowed in frames currently. Bug 17398)

frameless

• normal link target
  • default: <img> alt attribute is the caption, <a> title attribute ("Description page of Filename" ????)
  • alt= explicitly set an alt text (possibly empty value)
• explicitly set link target (Likely navigational element)
  • default: <img> alt attribute is the caption, use the caption for the <a> title attribute.
  • alt= explicitly set an alt text (possibly empty value)
• NO link (link=) (Likely decorative)
  • default <img> alt attribute == caption, no title attribute
  • alt= explicitly set an alt text (possibly empty value)

Or do you want a default of no alt for link=explicit elements ? (I thought we recently changed this around)

This isn't so different from the current setup I think. Should be easy to fix. I note that most problems from content here are probably an issue of authors not knowing what syntax to use at what times, less a bug in the software.

Other issues are using decorative/navigational images that require attribution, under our current Attribution policies, such images require links to their description pages when used. The English wikipedia for that reason is trying to use as many public domain images for decorative and navigational links as possible. Not sure what the status is of skin images, and likely the WikiEditor needs quite some work.

ayg wrote:

This is all for elaborate historical reasons. I wanted to rationalize it a few years ago, but Brion didn't let me, on the basis that there might be people depending on it.

vlakoff wrote:

Should we consider adding a |title= parameter? One use case would be for providing tooltips for decorative frameless images. For example see http://en.wikipedia.org/wiki/Template:Increase

Retitled bug to reflect comment 4, since as comment 3 states, the existing alt/title defaults are historical. But sure, we should be able to arbitrarily override alt and title if desired.

Please note that the third item (purely decorative images) has been resolved meanwhile.

• aria-hidden="true" role="presentation" will serve that, see T204618.
• You will find on contemporary mw: some examples: The photo of Hackathon participants does not give any clue and will be suppressed, and the icons in the title bars of the blocks are redundant to the textual headline and shall be ignored.