https://bugzilla.wikimedia.org/show_bug.cgi?id=30113
--- Comment #25 from Daniel Friesen <mediawiki-b...@nadir-seen-fire.com> 2011-07-31 04:03:06 UTC --- A few more researched things to point out: The display:none; <img> trick will only work for FB. Logos are links, as a result the link is the only actionable area, if a text browser /did/ make <img> tags actionable to view the image that functionality would be voided out by the fact that the logo is a link and would instead go to the main page. Which brings me to my next point. jidanni's report on w3m and lynx's behavior on <img>s is false. w3m and lynx DO NOT turn <img> tags into pressable buttons, and DO NOT provide the ability to open up the src of an <img> tag. w3m and lynx take <img> tags and display the alt text as textual content, if there is no alt text nothing appears. Images including alt text are not made into links to the image. The image behavior seams to be a false report based on the fact that in MediaWiki by default we wrap an image in an <a> that links to the File: page, and that File: page contains an <a> that points to the source image. When arriving on that source image the browser detects a mimetype it cannot handle and opens the default program for that mimetype. Which to a normal user's computer, opens the image viewer program. Said functionality is not necessarily intended for the consumption of images, but rather in the hopes that give documents such as a .pdf, .doc, or audio file a disabled person's computer will be able to handle the media using it's default program in a way that the disabled user can interact with. So, opening an image associated with a <img>... not a text browser feature. Being able to view a logo from a text browser, not functionality expected from a text browser browsing the standard accessible web. Additionally I've been reviewing that Web accessibility page on WP, and the w3c links... I don't believe that accessibility standards consider the use of text based browsers by users who are capable of seeing to be an accessibility target. Users who cannot see and require the use of a screen reader for braille or auditory output are included of course. But users who are only have bad eyesight appear to be included not in the context of css-less text browsers, but in the context of full css-capable web browsers, with tweaks to have them display content larger. Which we DO actually have support for in ways some other websites don't (we use em's specifically for these users). So the claims that the ability to access the wiki's logo image from a text browser is relevant to web accessibility... those arguments are looking pretty void right now. Users who can actually see a logo should be using a css capable web browser. This bug looks limited to "Please make the logo show up in Facebook" now. Which naturally was NOT relevant when our practice of using a background-image started, as that started in MonoBook (actually no, pre monobook), and back then Facebook did not exist. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
