[edit] Delinking decorative images I understand the problem that linked images cause for screen readers, but I don't like throwing the baby out with the bathwater. How is one supposed to reach the image description page without a link? By viewing the page source and copy/pasting the file name into the search bar? Powers T 22:05, 16 November 2009 (UTC) - That's one way, but it's pretty awkward. I typically ask the browser to copy the link location and then paste from that. Or you can ask the browser for the image properties. Please see #Gadget for jumping to file page below for another possibility. Eubulides (talk) 23:47, 16 November 2009 (UTC)
- There is no link with a location to copy; that's my whole point. And the image properties still require you to copy+paste it into the search bar. Powers T 13:12, 17 November 2009 (UTC)
- Maybe it's browser-specific? I was talking about Firefox. You mouse over the image, hold down the right mouse button, and select "Copy
Link Image Location". Or, you mouse over the image and type "a" "o" while pressing the right mouse button. Admittedly it's not as convenient as it should be, which is why I proposed a gadget in the next thread. Eubulides (talk) 20:07, 17 November 2009 (UTC) - With Opera and Firefox: Mouse over the image, hold down the left mouse button, and move the image in the url bar. It will paste the url of the image, and bring you on the page. Dodoïste (talk) 22:58, 17 November 2009 (UTC)
- Ah, but I don't want the URL of the image; I want the image description page, so I can see who created the work and what its licensing is. Powers T 15:16, 18 November 2009 (UTC)
-
-
-
-
-
-
- To do that, you copy the link (using any of the techniques described so far). You'll get something like "
http://upload.wikimedia.org/wikipedia/en/thumb/4/4a/Commons-logo.svg/40px-Commons-logo.svg.png". Manually remove all but the penultimate file name component, and replace "upload.wikimedia.org" with "en.wikipedia/wiki/File:"; this results in a URL to the file page "http://en.wikipedia.org/wiki/File:Commons-logo.svg". - The problem is not limited to purely decorative images, by the way. It's also quite common in functional images. For example, {{Commons}} (used in 170,000 articles) uses an image File:Commons-logo.svg, but you can't get to that image's file page without using the technique described.
- Admittedly the technique is awkward, which is why I propose a gadget in the next section. The idea is to handle the general problem, including {{Commons}} etc,, in a general way.
- Eubulides (talk) 20:22, 18 November 2009 (UTC)
-
- Awkward to say the least, and as has been noted, problematic when the image is not public domain. I don't see "well we have that problem elsewhere too" as a legitimate argument in favor of the practice. Powers T 15:02, 19 November 2009 (UTC)
- The licensing issue is discussed in WP:ALT. The argument in favor of the practice is WP:ACCESSIBILITY. There is no perfect solution here, but we shouldn't sacrifice the real needs of visually impaired readers to gain a minor advantage for editors. Eubulides (talk) 17:48, 19 November 2009 (UTC)
- You're linking me to the very guideline I'm here to discuss. So now we're back to the beginning again: "I understand the problem that linked images cause for screen readers, but I don't like throwing the baby out with the bathwater. How is one supposed to reach the image description page without a link?" (emphasis added) Powers T 19:51, 19 November 2009 (UTC)
- I've described the procedure above. It is awkward, but it works. A less-awkward procedure is proposed in the next thread. Eubulides (talk) 05:55, 20 November 2009 (UTC)
- I don't think either of those things is an acceptable substitute. Powers T 12:31, 20 November 2009 (UTC)
-
-
-
- I'm using Firefox. If the link is removed, there is no link to "Copy Link Location". Look at the example in Wikipedia:Alternative text for images#Purely decorative images. I right-click on the Japanese flag, and because there is no link, there is no option on the right-click menu for "Copy link location". Powers T 15:16, 18 November 2009 (UTC)
- Sorry, I should have written "Copy Image Location", not "Copy Link Location". I've corrected my comment above. Eubulides (talk) 20:22, 18 November 2009 (UTC)
- This is still nonsense. Despite what you said, delinking the image violates the CC license if the author's identification DOESN'T appear in the image or metadata, which is often the case. One could argue that delinking the image may violate the license even if the licensing information does appear in the image or metadata, if relevant licensing is on the image's talk page. — Arthur Rubin (talk) 16:11, 22 November 2009 (UTC)
- The previous comment appears to be based on a misunderstanding. Nothing in this discussion is about delinking images with a CC-BY-SA license. Furthermore, Purely decorative images does not say that such images should be delinked, unless the images themselves contain proper attribution, so I don't understand why the section was tagged. What wording in that section is being disputed? Is there some specific wording change you'd like to see installed? Eubulides (talk) 02:50, 23 November 2009 (UTC)
- Actually, when I added the "disputed" tag, your new recommendation was to delink "purely decorative images", regardless of license. The recommendation to delink is what I consider disputed. — Arthur Rubin (talk) 08:25, 23 November 2009 (UTC)
- It appears I misread the text; it may have been set invisible (or screen-reader-only) at the time. A later paragraph does state that the link should be present if it's a CC-by-SA image, and the license requires it. Your (personal) semi-automatic removal of links doesn't check whether the license allows that, but that may just be your personal mistake, rather than an error in the document. I still think the recommendation is disputed, but it's not necessarily a license violation. — Arthur Rubin (talk) 08:33, 23 November 2009 (UTC)
- That section has never set text to be invisible or screen-reader-only, as far as I know. I don't know what the phrase "Your (personal) semi-automatic removal of links" refers to: I don't have any bot or semiautomated tool that removes links. Anyway, whatever that phrase refers to, surely it has nothing to do with what's on this page. If there's a dispute, can you please state the dispute? Which wording in the page is incorrect, and what wording do you propose to replace it with? Eubulides (talk) 08:39, 23 November 2009 (UTC) (updated 09:04, 23 November 2009 (UTC))
- The dispute is over the assertion that "link=" is to be preferred for "purely decorative images". It improves readability for screen-readers (but not for text-based browsers such as Lynx), but makes it more difficult to verify licensing problems, possibly leading to automated tools, such as Betacommandbot, removing the images in case of a licensing dispute. Furthermore, it's not at all clear to me that the authorship being in the metadata is adequate for the CC-BY-SA license, even if the required licensure is only the author's name. — Arthur Rubin (talk) 09:28, 23 November 2009 (UTC)
- Please see #Delinking purely decorative images below. Eubulides (talk) 10:01, 23 November 2009 (UTC)
[edit] Delinking purely decorative images - 'The dispute is over the assertion that "link=" is to be preferred for "purely decorative images".' That part of the guideline reflects wide consensus, established by the W3C Web Accessibility Initiative, that purely decorative images should not be linked to. For example, please see section 1.1.1 of the Web Content Accessibility Guidelines (WCAG) 2.0.
- "It improves readability for screen-readers (but not for text-based browsers such as Lynx)," It improves readability for Lynx as well. I just now checked it with Lynx by looking at the examples in the Purely decorative images section.
- "possibly leading to automated tools, such as Betacommandbot, removing the images in case of a licensing dispute" Has that ever happened? If so, can you give an example? If not, can you explain why it might happen? (Sorry, I don't know about Betacommandbot.) (P.S. I just now looked into it, and User:BetacommandBot is blocked indefinitely, so this can't be a problem now. 10:10, 23 November 2009 (UTC))
- "it's not at all clear to me that the authorship being in the metadata is adequate for the CC-BY-SA license" Nothing in CC-BY-SA requires that attribution must be via a URL to a file page. The license doesn't even mention attribution via URL. All it says is that attribution must be done somehow. Attribution within the image itself clearly satisfies this requirement. In fact, it satisfies the requirement better than a file page does, because it works even in the presence of other random links to the image (which need not be links hosted by Wikipedia). For example, if some other Web site has a URL to <http://upload.wikimedia.org/wikipedia/commons/1/15/Red_Apple.jpg> then Wikipedia servers will deliver up that image to whoever visits the URL, in clear violation of that image's license. Attribution within the image's metadata would fix that problem.
Eubulides (talk) 10:01, 23 November 2009 (UTC) -
- Betacommandbot was not the only WP:NFCC-enforcing bot. I don't know the status of such bots; it's possible that should a bot would remove those images where the licensing information (not the author's name) is not contained in the image metadata. The author's name (which is what would usually appear in the metadata) is clearly not adequate licensing information.
- W3C is not Wikipedia, and there are clearly some W3C guidelines which are in violation of Wikipedia policies, so should not be done here. You would need to establish Wikipedia consensus for those parts of the W3C guidelines you want to include in Wikipedia guidelines, not just assert there is W3C consensus or a general Wikipedia consensus for the W3C guidelines. The present state of Wikipedia debate is that you added the guideline and have argued in favor, and I object to the removal of link=. Powers seems to have weighed in against it earlier in the above thread. No one else seems to have weighed in yet. That is not consensus in favor of overriding the default linkage by placing "link=". — Arthur Rubin (talk) 11:48, 23 November 2009 (UTC)
- I agree that it is not at all clear that "attribution in the metadata" is sufficient. I certainly have no idea how to access that metadata to determine authorship. And it doesn't help the situation where a delinked image is encountered, anyway, as I, as a reader, have no way to determine whether the image is freely licensed or not, and if it is, under what license, without jumping through an unreasonable number of hoops. In other words: given the presence of image description pages, following the W3C guidelines in this case is not practical. Powers T 12:12, 23 November 2009 (UTC)
- It was previously discussed at Wikipedia talk:Alternative text for images/Archive 3#Should we really be removing link from images? — Dispenser 14:01, 23 November 2009 (UTC)
-
-
-
-
- The idea that all media must go directly to the file page when you click on it, with no exceptions, flies in the face of many features that are commonly used in Wikipedia, and clearly does not reflect consensus on Wikipedia. If that idea were taken seriously, then <imagemap>'s
default feature could not be used; nor could {{Pronounced}} be used; nor could <div style="position:..."> be used as is commonly done in navigational templates; nor the [[Media:]] feature; nor the |link1= feature of {{Multiple image}}; nor any of lots of other common usages in Wikipedia. Millions of uses of media files in Wikipedia do not go to their file page when you click on them: it simply cannot be that all these uses violate copyright, or violate Wikipedia consensus. - "it's possible that should a bot would remove those images" I suppose it's possible that a malfunctioning bot could do anything. But that's not a practical argument against purely decorative images.
- "there are clearly some W3C guidelines which are in violation of Wikipedia policies" None of the W3C Web Accessibility Initiative (WAI) guidelines violate Wikipedia policies. And no such conflict is discussed in Wikipedia:Accessibility: on the contrary, that page cites the WAI guidelines, in multiple places, without mentioning any conflicts.
- "You would need to establish Wikipedia consensus" That was done here, in earlier discussion. And consensus clearly exists for many other Wikipedia features, as described in the first bullet of this comment. The argument for supporting visually impaired readers is a strong one: it is not overcome by these relatively weak arguments about difficulty of auditing for copyright compliance.
- "I, as a reader, have no way to determine whether the image is freely licensed or not" Any delinked image must be freely licensed. Nobody is arguing that non-free images should be displayed without links, and Wikipedia articles never display non-free images without links. If you like, we can add explicit text to that effect on this page, to address these concerns.
- "and if it is, under what license, without jumping through an unreasonable number of hoops"" It's not an unreasonable number of hoops. It's a very simple process, which (as a result of this discussion) was recently documented in Help:File page #File page location.
- "I certainly have no idea how to access that metadata to determine authorship." Copyright licenses such as CC-BY-SA do not require that attribution must be done in such a way that any reader can see the attribution without doing any work whatsoever. (If such were required, attribution via link-to-file-page would not suffice either, as many readers are completely unaware of these links.) All that's required is that attribution be done so that anyone seriously interested in finding out the author can do so, which is clearly the case when there's attribution in (say) a JPEG file's comment field.
- Auditing images for proper attribution is much simpler than the process of auditing the text in a Wikipedia article for copyright compliance. Take, for example, the following sentence randomly chosen from today's featured article, Grover Cleveland: "Having succeeded in reversing the Harrison administration's silver policy, Cleveland sought next to reverse the effects of the McKinley tariff." This sentence was contributed under the CC-BY-SA, which requires attribution. OK, which Wikipedia editor contributed it, and when? To find that out, one must search through all 3,636 edits to that page until one finds the edit that contributed that sentence. This is a much more cumbersome process than the simple procedure documented in File page location for images.
- "given the presence of image description pages, following the W3C guidelines in this case is not practical" This argument is backwards. File pages provide one way to attribute images; they are not the only way. The existence of one way to attribute images and satisfy W3C guidelines does not make it impractical to use other ways to achieve the same goals.
- Eubulides (talk) 20:16, 23 November 2009 (UTC)
-
-
-
-
-
- No comment on whether W3C guidelines are contrary to Wikipedia guidelines. I don't think they are, but I think you're misinterpreting Wikipedia guidelines (other than the one to which you just WP:BOLDly added the recommendation not to link.)
- I should have said that it's likely a bot would correctly remove images where the license was found (even incorrectly) to be invalid. Not removing the link would make it easier to fix the problem.
- The earlier discussion clearly did not establish consensus for removing the link for decorative images. The only arguments presented in favor or statements presented in agreement with it were by you.
- A minor point; the author's name being in the image metadata does not mean that the licensing information is there. I tend to agree that anything in the metadata can be considered "attributed", but CC-by-SA may not appear in the metadata even if the author's name is. You seemed to be saying that the author's name in the metadata would be adequate licensing.
- File pages provide the Wikimedia-preferred way to report licensing information; other links or URLs may be suitable attribution, but I don't see how a rewrite rule could be allowable unless it was specified somewhere in Wikipedia's licensing documentation.
-
-
- Not here; describing the method in WP:CC-BY-SA or an equally visible page would be adequate.
- Not there, either. The section you recently added, even if accurate, does not seem to provide an adequate pointer.
- I suppose it needs to be said at least once; that I did not state that I disagreed with one of your statements does not mean that I agree with it. — Arthur Rubin (talk) 21:41, 23 November 2009 (UTC)
-
-
-
-
-
-
- "You seemed to be saying that the author's name in the metadata would be adequate licensing." Sorry, I did not mean to imply that. The metadata should also contain a pointer to (or copy of) the license, if we want to support links from other web sites directly to a CC-BY-SA image. However, if all we want to support are links from Wikipedia pages, then it's OK for the metadata to omit the pointer to (or copy of) the license, since every Wikipedia page already contains a pointer to the CC-BY-SA license, and this satisfies that part of the licensing terms.
- "No comment on whether W3C guidelines are contrary to Wikipedia guidelines. I don't think they are" OK, so (if I understand your comment correctly) we're in agreement on that point.
- "it's likely a bot would correctly remove images where the license was found (even incorrectly) to be invalid" Sorry, I don't understand the scenario. At any rate, this appears to be a theoretical issue, as no such bot is in operation.
- "The earlier discussion clearly did not establish consensus for removing the link" Sorry, I was referring to different discussions. Wikipedia:Media copyright questions/Archive/2009/July #W3C accessibility guidelines and image copyright notices established a consensus that it's OK to attribute via metadata in the file, and that public-domain images do not need links. I'm sure there are other discussions as well; there is longstanding consensus that public domain images do not need attribution links.
- "I don't see how a rewrite rule could be allowable unless it was specified somewhere in Wikipedia's licensing documentation". That argument implies that attribution via file pages is not allowable because file pages are not specified anywhere in CC-BY-SA-3.0 (which they are not). But that would be an absurd conclusion, because that sort of attribution is obviously allowable. Thefore, the argument is not a valid one.
- Eubulides (talk) 05:54, 24 November 2009 (UTC)
-
- OK, concur that the image metadata is sufficient attribution, provided that all the required attribution is there. It seems to me that any URI required by the author per provision 4(c)(iii) would have to be included in the attribution we have, somehow. "To the extent practical" overrides W3C accessibility guidelines.
- Immediately after BetacommandBot was banned, a version enforcing another (disputed) interpretation of WP:NFCC was created and run by non-controversial admins. However, it appears to depend on whether the licensing information properly appears in the File: section, rather than in the pointer, so it's not relevant to this discussion. My mistake.
- It appears that we are finding fewer disagreements as time goes by. Perhaps you're correct. — Arthur Rubin (talk) 07:57, 24 November 2009 (UTC)
-
- OK, thanks, I clarified the point raised above about non-free images, and removed the tag. If there's any further wording improvements that could help, please let us know. Eubulides (talk) 19:13, 25 November 2009 (UTC)
[edit] Template:Infobox Theatre Template:Infobox Theatre needs an alt text parameter for use at Jay Pritzker Pavilion.--TonyTheTiger (t/c/bio/WP:CHICAGO/WP:FOUR) 06:17, 25 November 2009 (UTC) - Done. Eubulides (talk) 06:37, 25 November 2009 (UTC)
[edit] Image maps How does one add ALT text to image maps? Jay Pritzker Pavilion and all the Millennium Park articles all have the same image map, which needs ALT text. Thanks in advance, Ruhrfisch ><>°° 05:46, 29 November 2009 (UTC) - I added a section Image maps to answer this question. Thanks for finding the hole in the guideline. Eubulides (talk) 10:11, 29 November 2009 (UTC)
A "standard" WP:ROUTE diagram consisting 60+ icons | | This route map: view • talk • edit | | As ALT text is growingly becoming the standard for FA. Transport articles which use the Wikipedia:route diagram template (WP:ROUTE or RDT) to draw the map got the problem that we have no solution for how to display the well written ALT text for the diagram. Simply put, the WP:ROUTE is a series of templates to build up a table by applying the proper icon images out of 3000+ and joining them cohesively which resembles a line map. Should we consider the whole map is a "single image" and repeat the same ALT for each icon image or write different ALT text for each icon image individually? Thx -- Sameboat - 同舟 (talk) 02:19, 1 December 2009 (UTC) - I am following this up in Wikipedia talk:Route diagram template #Alt text in route diagrams. Eubulides (talk) 08:18, 1 December 2009 (UTC)
[edit] Describing a book or publication Several of the articles I've worked on contain the front pages of out-of-copyright books, newspapers, and pamphlets. How should we describe these with alt text? For instance, on Dick Turpin? Parrot of Doom 16:09, 2 December 2009 (UTC) - I added a suggestion for that to the Text section. Eubulides (talk) 20:06, 2 December 2009 (UTC)
[edit] Using "caption" attribute for alt text in infoboxes Hey folks, So {{infobox lake}} uses a hack which means that if either of the images included in the template don't have alt text specified, then this is derived from the image caption. I'm pretty sure that this is a bad idea (as caption text isn't likely to be useful as alt text in this case, and because it's going to result in duplicated text for screen readers) but I've been unable to convince Docu (talk · contribs), who is watching said template. I've implemented a compromise which at least allows for proper alt text to be specified for now, but any further input would be helpful. Chris Cunningham (not at work) - talk 09:39, 4 December 2009 (UTC) |