(Should this be assigned to Content Model? Parser? Rendering? Viewer App?) The longdesc attribute of the IMG element contains a link to a file describing the image in detail, for those times where the image cannot be downloaded. The browser should supply some way of accessing this information. See also bug #1995

While application behavior is outside the scope of the layout engine, it would be good to figure out what we should do with ALT/TITLE/LONGDESC and then forward that information to the appropriate app developers or change our default behavior for the image frame class.

We do, you can access it through the DOM. See GetLongDesc() and SetLongDesc() in nsIDOMHTMLImageElement or the W3C DOM spec

Page moved. Updating uri.

Re-opened the bug, because it was pointed out to me that just providing DOM access to the LONGDESC wasn't all that useful. Marking it REMIND, because it's not something we're planning on doing for version 1.0

QA Assigning to self.

Verifying 'REMIND'.

Since bug 1995 is now under consideration, and it is very similar, I am reopening this bug.

Troy, you may wish to reassign this bug to german/don/shuang in UE, as this will probably require a spec before it can be implemented.

This still isn't going to get implemented for version 1.0 so I'm marking it back as REMIND

Rubberstamping as verified/REMIND.

Troy no longer with us, so reassigning. Since Troy says that DOM access is indeed provided, and that all that is missing is the XUL interface to this, marking "helpneeded" and reassigning to nobody. Setting milestone to Future. If anyone wants to do this, it should be relatively easy: Add a menu item to the popup menu for images. Disable it by default. When the menu is popped up, check (using "GetLongDesc()") if the image has a LongDesc URI, and if it does, enable the menu item. If the menu item is selected, then fetch the URI for the image using "GetLongDesc()" again, and navigate to that page. For extra credit, make the status line text for that menu item contain the URI of the pointed to by the "longdesc" attribute. :-)

Reassigning...

Added a depend on Bug 42066. GetLongDesc() only returns a relative URI right now, and it needs to return an absolute URI.

Taking QA per managerial policy.

Changing dependency on bug 42066 to bug 47534, since this takes over the problem of longdesc (among others) returning a relative URL.

In addition to longdesc on images, it would also be nice if the Frame context menu provided access to the longdesc on the current frame. Along the same lines, it would also be desirable if the context menu made the cite attribute on BLOCKQUOTE/Q/INS/DEL navigable. See bug 37209.

I've got a patch for this adding IMG longdesc support to the context menu. However, I've heard that cluttering up the context menu with this (since I plan to add support for FRAME longdesc and the cite attribute as well) may not be the best idea, and I should put it in the sidebar. Anyone care to comment on where this metadata should go?

The patch adds "View Image Long Description" and "View [element] Citation" to the context menu as appropriate. The second function isn't very robust yet, though.

This patch has been sitting here a while. Should "review" be added?

Actually, I think it's been obsoleted by the patch for bug 1995, which seems to have stalled in review.

This is *not* obsoleted by bug 1995; this bug is for a context menu option and not all the additional stuff like panels and so on. Blake: could you have a look at the patch and do something with it? Cheers...

The reason I made my comment was that the current context-menu UI spec just lists a single item "Imtage Properties" which should presumably cover all the metadata, and mpt's comments in bug 26939 suggest he's looking to keep bloat out of the context menus. Feel free to mine the patch for whatever changes you like, though.

This bug isn't so much about metadata as one click access to links to more information. "longdesc" is a URI -- a context menu option is a considerably quicker way of getting to this information that a "middle man" window. (Not that the metadata window is a bad idea, I think it's great, it's just not a replacement for _this_ bug.) Similary with "cite". Your patch looks great to _me_, but I'm not an expert at all in this code, so I'll defer to Blake.

Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...

Them longdesc metainfo is now avalible through the "properties" window from bug 1995, so feel free to mark as fixed

Can we not close this just yet? The trouble with the current setup is that one has to enter the properties window from the context menu to click the longdesc link. Not many people will realize that it's there, which will discourage its use by authors. Ideally, I think that the longdesc should be somewhere in the context menu (as in my patch above), but mpt has been pretty assertive about not wanting more items in the context menu. Can someone with more UI experience suggest a good, quickly accessible place to put longdesc?

i have a design idea that would result in a powerful tooltip replacement for the properties dialog, it would easily handle most of the problems relating to contextual objects, however i don't have the time to work on it right now. (oh and it won't fit in the margins of this comment either, !exist a^n+b^n=c^n forall positive integers a,b,c, where n>2)

The W3C TUAAG <URL: http://www.w3.org/TR/UAAG10-TECHS/#long-descriptions > says: Allow the user to configure how the user agent renders a long description (e.g., "longdesc" in HTML 4 [HTML4]). Some possibilities include: * Render the long description in a separate view. * Render the long description in place of the associated element. * Do not render the long description, but allow the user to query whether an element has an associated long description (e.g., with a context-sensitive menu) and provide access to it. * Use an icon (with a text equivalent) to indicate the presence of a long description. * Use an audio cue to indicate the presence of a long description when the user navigates to the element.

The W3C TUAAG also says that it is a collection of suggestions, rather than a collection of requirements. I am of the opinion that providing preferences for configuring the display of longdesc would harm usability (`help, I don't understand all these prefs!') more than it would improve accessibility. Given that longdesc is (I assume) hardly used, it's just not important enough to have prefs for. However, we do have a problem in that where a `longdesc' is present, its existence is hardly noticable. You have to go into a context menu item (which is identical whether or not the item has longdesc), then look in the resulting window, and finally click a link in order to open the longdesc page (which blows away the original page). I suggest three things to solve this problem. 1. When an image has a longdesc, by default it should be given the cursor which indicates the existence of a context menu (that is: img[longdesc] {cursor: context-menu}). In this case, the cursor indicates that information provided by the author is available for the item. This should also apply to frames, but only when frames are turned off (i.e. the cursor applies to the Lynx-like link to the frame, not to the frame itself). Potential problem: this may give Mac users the impression that their Control key is stuck. Perhaps we should use {cursor: help} instead? 2. The `Properties' item should be renamed to `Image Info', `Frame Info', or `Page Info' as appropriate, with the `Page Info' and Page Properties windows being merged (bug 74729.) When an item has a longdesc, the item should instead be labelled `Image Info and Description' or `Frame Info and Description'. (Unlike the cursor, this would apply to a frame even when frames were turned on.) 3. The longdesc document should be shown in a box inside the Info window, rather than in a browser window. Since we will be the first major browser to support longdesc, we can dictate a convention that a longdesc document works best if it is a small one. There should be an `Open in Browser' button under the box, to allow the longdesc page to be opened in an ordinary browser window for saving, printing, better viewing, or whatever; in addition, any links followed from the longdesc page should open in a browser window rather than opening in the box. This proposal does not address how longdesc should be handled in a future speech interface to Mozilla; but since that will require a completely new set of HTML compliance speccing, it can be left for another time. Please discuss this proposal in the thread `Bug 1996: Support LONGDESC for IMG and FRAME' in the m.ui group and the mozilla-accessibility mailing list.

I think that with the new description for this, bug 3658 can be marked a duplicate of this bug (it covers frame/iframe support specifically).

Check out bug 74121, which is about cleaning up the Properties window to be more UI friendly and logical...

Bug 3658 is for frame/iframe longdesc support

Ok, I lost this bug. Sorry about that. My previous specification applies, with the exception that the word `Properties' is used instead of `Info'. --> Layout (since HTML Elements is deprecated).

not a table bug, over to attinasi

Since the contents of the image properties dialog, accessed from the context menu, displays the image location and it is a valid link to the longdesc, I am marking this bug as resolved/fixed. Attaching a testcase for tracking purposes

To verify: 1. open testcase in browser window 2. On windows, mouse-over the netscape logo, right mouse click and select properties. 3. The URI displayed next to the Description label is the content of the longdesc attribute, select the URI Result: the DevEdge page should be rendered

Marking verified in the Nov 20th build. The URI for longdesc is displayed in Image Properties dialog and is functional. However, we still haven't implemented support for LONGDESC with iframe/frames elements. http://bugzilla.mozilla.org/show_bug.cgi?id=3658

Using Mozilla 1.2.1 I can find no direct way to access the longdesc URI of an IMG. Page Info->Media shows the longdesc, but it's shown as a relative URI (if given as a relative URI) and isn't an active link. The Properties dialog shows the URI but again, it isn't a link (trying the test case given in comment 37, I can't select the URL) This means I have to highlight and copy the URI, and paste it to the Location bar to access it. Has this changed since this bug was marked fixed? Should I open it as a new bug?

I agree; the link to the longdesc URI should be functional. Reopening.

And this is related to "layout" _HOW_ exactly? ;)

this looks like something I could fix someday so adding CC

In a fix for bug 101910, the onclick and class attributes were not transferred to the new elements. Because of this, the links no longer looked like links and did not function as links. I have fixed this by adding class="text-link" onclick="openLink(this);" to the appropriate XUL elements. I have tested this locally and it works with no noticed regressions.

Comment on attachment 123948 [details] [diff] [review] fixing regression from 101910 to make links clickable again requesting review by sicking (original author) and superreview from caillon since he's around right now

Comment on attachment 123948 [details] [diff] [review] fixing regression from 101910 to make links clickable again Sorry. I'm not a superreviewer. Try jag.

Comment on attachment 123948 [details] [diff] [review] fixing regression from 101910 to make links clickable again changing superreiver request, caillon's not superreviewer

received a message from Neil Marshall who wrote the patch causing the regression. He said it was intentional so that the links could be copied. They can't be copied with the linkification. So, we have a decision to make: Do we want to be able to copy the URLs or to click them? It seems the two are mutually exclusive. Since the labels cannot be copied and most other dialogs can't be copied, I opt for the linkification, but other feedback is obviously necessary before this were actually checked in.

It seems to me that linkifying would make more sense; after all, you're supposed to be able to browse these URLs, and that's more convenient than copy-and-paste to URL bar. Is inability to copy linked text a bug?

Shouldn't you be able to right click the link and choose "Copy"?

In a subsequent e-mail from Neil, he suggested adding a button to follow the link. I think that would just be moving the onclick action to the button and then the text can still be copied. But then, that would be a workaround for what might be considered a bug, which might be discouraged. Any other ideas?

Comment on attachment 123948 [details] [diff] [review] fixing regression from 101910 to make links clickable again r=sicking for this patch. However make sure that you get somebody from UI to superreview this, I'm not sure who qualifies for that these days. Also note that this bug has previously been considered something different then the metadata window (see comment 22), so you might not want to close this bug after applying this patch

This patch uses a button instead for the onclick event. However, the URL text is sometimes truncated. Ideas?

Are you sure it's truncated and not just off the edge of the textbox? They were put into textboxes so that the entire url is visible and it doesn't change the size of the dialog box. Windows does the same thing in it's properties dialog boxes.

Comment on attachment 123948 [details] [diff] [review] fixing regression from 101910 to make links clickable again unsetting approval request until this has reviews.

Neil: it is just off the edge of the dialog boxes. If I highlight the URL, it will scroll so that it can completely be seen. So, do we want this buttoned version instead?

(Sorry for taking so long to check the patch out) hm, the problem with it is that it looks ugly because the buttons so big and it's throwing off the layout. (Not to mention the blue text creating weird underlines in the right click menu under modern) What if the go and copy were both accessable in the right click menu? Then it wouldn't matter if the link was clickable or not (it could be either depending on what people want). Does anyone else have any ideas?

*** Bug 197025 has been marked as a duplicate of this bug. ***

Comment on attachment 123948 [details] [diff] [review] fixing regression from 101910 to make links clickable again This "text-link" class causes the text in the context menu to become underlined. I think I would prefer this approach (once fixed) though over adding a separate button. For now users could Select All, Copy to get the text of the url, perhaps in the future we could add a "Copy Link" item to make it easier.

I confirmed the issue mentioned by jag and think it could be fixed by adding a style rule like [class="text-link"] xul:popup { text-decoration: none; color: black } or something along those lines. Would that work. As for Neil's issue with not being able to copy it, is it possible to make a child element of the input box that is like a span. We could then have <address> where the '<' and '>' are not linkified. That way the URL could be copied if need be.

Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). If you want this fixed for Firefox, change the Product and Component accordingly and reassign back to me.

(In reply to comment #30) > However, we do have a problem in that where a `longdesc' is present, its > existence is hardly noticable. (...) When an image has a longdesc, by default it > should be given the cursor which indicates the existence of a context menu (that > is: img[longdesc] {cursor: context-menu}). Marking this bug dependent on bug 258960.

(For what it's worth, which probably isn't much since I can't imagine this ever appearing in Firefox: I now think it's not worth the menu-and-cursor clutter for a *graphical* browser to provide an obvious interface to longdesc=. That attribute was well-intentioned but is destined to hardly ever be used; alt= is much more practical for accessibility purposes.)

For fans of this bug, there is since Feb. 13th a Firefox extension, Longdesc 0.21, which makes an image longdesc link attribute accessible via context menu. You can try it: https://addons.update.mozilla.org/extensions/moreinfo.php?application=firefox&version=1.0+&os=nt&id=273

(In reply to comment #63) > ... Firefox extension, Longdesc 0.21, which makes an image longdesc link > attribute accessible via context menu. It would be nice to see this merged with the Firefox accessibility extension being build by Jon Gunderson's team at UICU

(In reply to comment #64) > (In reply to comment #63) > > ... Firefox extension, Longdesc 0.21, which makes an image longdesc link > > attribute accessible via context menu. > It would be nice to see this merged with the Firefox accessibility extension > being build by Jon Gunderson's team at UICU > > It is already a part of the Firefox Accessibility Extension up the list of images option. There is a button to open long descriptions. Jon

The extension longdesc-0.21-fx+mz.xpi also works perfectly for Seamonkey 1.0a and 1.1a. So, once/thanks to this extension registered and associated to a profile, this bugfile is FIXED for practical reasons as far as I'm concerned.

*** Bug 321622 has been marked as a duplicate of this bug. ***

In spite of possible extensions that support longdesc, it really is the task of the *browser* to provide access to this information. (IMO the browser isn't complete when it doesn't actually support HTML completely.) Firefox already has excellent data in its images properties, which includes the longdesc *URL*. It would be great if that URL were made into a clickable *link*. I suspect it would also be easy to do. BTW, neither the Firefox Accessibility Extension () nor the longdesc extension (longdesc_0.5.xpi) - both mentioned in this thread - are currently usable with Firefox 3b5. This demonstrates precisely the problem with extensions that "repair" an omission in the browser itself; they may not get updated for a major new browser version, thus leaving the browser "unrepaired" again.

It looks like this bug was filed against the Mozilla Application Suite (SeaMonkey). Bug 216086 was for Firefox.

Marjolein, I completely agree with every points you made and your point of view. Regarding "URL were made into a clickable *link*", this was the case before, in earlier releases. Ex. given: NS 7.0 (rv:1.0.1 Gecko/20020823) has the URL linkified. but with NS 7.2 (rv:1.7.2 Gecko/20040804), the link of the longdesc URI is plain text, not blue, linkified, clickable. One issue which may stop or refrain Mozilla (and other browsers) from fully implementing longdesc (that is: in the browser, not as an add-on and with linkification) or investing further dev. time and energy is that it may no longer be needed, required for HTML5. Some browser manufacturers may/will think: why implement longdesc if it won't be required in HTML5 anyway? Why work on implementing (or completing the implementation of) an attribute which won't be needed anyway later? http://www.whatwg.org/specs/web-apps/current-work/#the-img "There has been some suggestion that the longdesc attribute from HTML4, or some other mechanism that is more powerful than alt="", should be included. This has not yet been considered."

(In reply to comment #70) > Regarding "URL were made into a clickable *link*", this was the case before, in > earlier releases. > Ex. given: NS 7.0 (rv:1.0.1 Gecko/20020823) has the URL linkified. > but with NS 7.2 (rv:1.7.2 Gecko/20040804), the link of the longdesc URI is > plain text, not blue, linkified, clickable. Thanks for pointing that out; I've had a few versions of NS for testing but have never been a real user, so I didn't know that. > One issue which may stop or refrain Mozilla (and other browsers) from fully > implementing longdesc (that is: in the browser, not as an add-on and with > linkification) or investing further dev. time and energy is that it may no > longer be needed, required for HTML5. Some browser manufacturers may/will > think: why implement longdesc if it won't be required in HTML5 anyway? Why > work on implementing (or completing the implementation of) an attribute which > won't be needed anyway later? Well, developing a standard is not the same thing as developing a browser - even if some of the same people may be doing both. I actually read a long discussion on longdesc and HTML5 today. It is true longdesc may not be the ideal solution to a real problem, but given that the problem is real, HTML5 should, one way or another, provide "a" solution, ideal or not, and make clear (as HTML4 did) that there is a problem to be solved. Merely discarding longdesc because it's not ideal is not helpful at this stage. But it may be years before HTML will reach recommendation stage. Surely Firefox 3 will not take that long. There is no way the browser maker (as opposed to the standards WG member) can even consider to only implement what /may/ be in an future standard. The browser needs to support what is out there, now. Not just in the HTML4 / XHTML standards, but in real use in real documents out there. When HTML5 becomes a standard, it won't magically make those real, existing documents disappear. So the browser needs to support not just what /may/ be coming, but first and foremost what is out there already and compliant with the *current* standard. (The browser supports even things that were in previous standards, after all, precisely because there are still documents that use those features.) It [support for longdesc] will be needed, as it always was needed. It's about time, I think. > http://www.whatwg.org/specs/web-apps/current-work/#the-img > "There has been some suggestion that the longdesc attribute from HTML4, or > some other mechanism that is more powerful than alt="", should be included. > This has not yet been considered." It should be, but that's another discussion. :)

Back around 2001-2002, it was decided to make the longdesc URL accessible, fetchable in the properties window to avoid cluttering the right-click-contextmenu: see comments #17, #23 in this bug. Firefox 2.x does that. Firefox 3 does that (as far as I know). Seamonkey 2.0a1 rv:1.9pre does that. Linkification of the longdesc URL is another issue: problem, it seems, is how to copy linkified text. The extension longdesc-0.21-fx+mz.xpi works for Seamonkey 1.x but not Seamonkey 2.x

WCAG 2.0 Candidate Recommendation (April 30th 2008) Techniques for WCAG 2.0 H45: Using longdesc http://www.w3.org/TR/2008/WD-WCAG20-TECHS-20080430/H45.html

Mass un-assigning bugs assigned to Aaron.

Shouldn't this be WONTFIX now that HTML5 obsoletes longdesc?

Why? Shouldn't SeaMonkey still support HTML 4?

(In reply to comment #76) > Why? Shouldn't SeaMonkey still support HTML 4? There's really no point in *adding* support for obsolete features. HTML 4 as a whole is obsolete as an implementation target.

Henri, while I agree there is little demand or justification, comment #71 already makes a valid argument why support should be added in principle. Being "obsolete as an implementation target" is irrelevant to the fact that HTML 4 documents exist, and can still legitimately be created, because the browser should support valid uses of valid attributes if it claims to be compatible with any prior standards. Nevertheless, I recognize this bug is simply an example of ignoring problems until they go away. It's part of human nature.

> I recognize this bug is simply an example of ignoring problems > until they go away. That certainly seems to be the bugzilla.mozilla.org approach, for every bug I can remember submitting or being CC'd on

http://www.w3schools.com/tags/att_img_longdesc.asp The longdesc attribute is not supported by any of the major browsers. WONTFIX parity-ie parity-fx parity-chrome parity-opera parity-safari

(In reply to Philip Chee from comment #80) > The longdesc attribute is not supported by any of the major browsers. > > WONTFIX parity-ie parity-fx parity-chrome parity-opera parity-safari Parity? What's wrong with making Mozilla's standards support better than IE, Chrome, Opera, and Safari?

(In reply to Robin Lionheart from comment #81) > (In reply to Philip Chee from comment #80) > > The longdesc attribute is not supported by any of the major browsers. > > > > WONTFIX parity-ie parity-fx parity-chrome parity-opera parity-safari > > Parity? What's wrong with making Mozilla's standards support better than IE, > Chrome, Opera, and Safari? Longdesc is flawed as a feature of an obsolete standard (HTML4). See permathreads on http://lists.w3.org/Archives/Public/public-html/ over the last few years.

(In reply to Robin Lionheart from comment #81) > (In reply to Philip Chee from comment #80) > > The longdesc attribute is not supported by any of the major browsers. > > > > WONTFIX parity-ie parity-fx parity-chrome parity-opera parity-safari > > Parity? What's wrong with making Mozilla's standards support better than IE, > Chrome, Opera, and Safari? For longdesc implementation information please visit: http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementation Opera indeed added native support for longdesc in 2009. http://www.opera.com/docs/changelogs/mac/1010b1/#ui iCab has had native support for longdesc long before then. ISSUE-30: longdesc is an open issue in HTML5. http://www.w3.org/html/wg/tracker/issues/30 People are using longdesc.

Usual Mozilla behavior: let a spec-related bug rot for 14 years, then claim that web developers don't use the feature, that the spec is flawed/not useful/not clear/no one else is using it. The irony is that web developers don't use the feature because browsers don't implement it. And browsers don't implement the feature because they say that web developers aren't using it. And let's not forget to dismiss any non-developer comments on the bug report as not helpful and in violation of Bugzilla's etiquette. We've seen this behavior before. We'll probably keep seeing it. Mozilla devs —in general— lack self-criticism.

(In reply to Carlos Alén Silva from comment #84) > Usual Mozilla behavior: let a spec-related bug rot for 14 years, then claim > that web developers don't use the feature, that the spec is flawed/not > useful/not clear/no one else is using it. The irony is that web developers > don't use the feature because browsers don't implement it. And browsers > don't implement the feature because they say that web developers aren't > using it. During the past year alone, numerous organizations such as the A11y Bugs Project, Aboriginal Affairs and Northern Development Canada, Axel Schäfer, SPD Abgeordneter im Deutschen Bundestag für Bochum, CSS Squirrel, Canadian Department of Justice, Canadian Space Agency, Correctional Service Canada, Department of Transportation (Taiwan), Courts Administration Service (Canada), Daegu Metropolitan Office of Education (South Korea), Office of the Superintendent of Financial Institutions Canada, Elections Canada, Environment Canada, Hipocampo, HTML Accessibility Task Force, HTML5 Multimedia, Kyungpook (South Korea), Marine National Park (Taiwan), Michigan State University, National Center on Birth Defects and Developmental Disabilities, Object Description, Ohlone College, University (South Korea), Oracle, Oriental Hospital of Daejeon University (South Korea), Panel on Responsible Conduct of Research (Canada), Parcs Canada, Parks Canada, Paris Web, Parliament of Canada , Public Safety Canada, Public Works and Government Services Canada, Rebuilding The Web, Social Security Online, Secrétariat du Conseil du Trésor du Canada, Les rapports sur les plans et les priorités, Special Education Support Center (South Korea), Statistics Canada, Statistique Canada, Substance Abuse & Mental Health Services Administration, Treasury Board of Canada Secretariat, Texas State Library, U.S. Department of Health & Human Services, and the University of Minnesota have used it in reports and publications. Notably two sister sites Statistics Canada and Statistique Canada began consistently using longdesc in "The Daily" publication. "The Daily" produces statistics on a business-day basis that help Canadians better understand their country, its population, resources, economy, society and culture. On July 29, 2011 Suzanne Taylor and Ed McCoyd, Esq., of the Association of American Publishers attested: "We are using longdesc increasingly in our products."

I am disappointed by the WONTFIX resolution of this bug report. Longdesc 0.8 add-on extension for Firefox by Patrick H. Lauke https://en.add-ons.mozilla.com/en-US/firefox/addon/longdesc/ longdesk 0.2 add-on extension for Firefox by Anthony https://en.add-ons.mozilla.com/en-US/firefox/addon/longdesk/ ------------ IE8 supports longdesc natively, without any extension. " The target of the longDesc attribute is now displayed as the tooltip, if present; otherwise, the title is displayed. " http://msdn.microsoft.com/en-us/library/ie/ms534132%28v=vs.85%29.aspx ---------- As mentioned in comment #70, NS 7.0 and NS 7.2 supported the longdesc attribute. Gérard

(In reply to Gérard Talbot from comment #86) > I am disappointed by the WONTFIX resolution of this bug report. > > > Longdesc 0.8 add-on extension for Firefox by Patrick H. Lauke > https://en.add-ons.mozilla.com/en-US/firefox/addon/longdesc/ > > > longdesk 0.2 add-on extension for Firefox by Anthony > https://en.add-ons.mozilla.com/en-US/firefox/addon/longdesk/ > > ------------ > > IE8 supports longdesc natively, without any extension. > > " > The target of the longDesc attribute is now displayed as the tooltip, if > present; otherwise, the title is displayed. > " > http://msdn.microsoft.com/en-us/library/ie/ms534132%28v=vs.85%29.aspx > > ---------- > > As mentioned in comment #70, NS 7.0 and NS 7.2 supported the longdesc > attribute. > > > Gérard NVDA will now "announce the existance of the long description, and you can press NVDA+d to open it. Works in Gecko (Firefox) and MSHTML (Internet Explorer)." http://www.nvda-project.org/ticket/809#comment:7

Phillip's reason for closure was incorrect. Putting parity-opera on the whiteboard.

> Works in Gecko (Firefox) SeaMonkey is Gecko too. Do you have an example of a webpage with long descriptions that work in Firefox but not in SeaMonkey?

HTML5 Image Description Extension Abstract: "This specification defines a longdesc attribute to extended descriptions to images in HTML5-based content." https://dvcs.w3.org/hg/html-proposals/raw-file/b63325998cc1/longdesc1/longdesc.html

(In reply to Philip Chee from comment #89) > SeaMonkey is Gecko too. Yes. > Do you have an example of a webpage with long > descriptions that work in Firefox but not in SeaMonkey? No.

Chris Kennish just released a new chrome plugin providing image highlighting and right-click access to longdesc. It is available at: https://chrome.google.com/webstore/detail/longdesc/haohljalgapbacpkfefnmhiadanhejmb

(In reply to Henri Sivonen (:hsivonen) from comment #75) > Shouldn't this be WONTFIX now that HTML5 obsoletes longdesc? longdesc is a valid HTML5 attribute. HTML Image Description Extension Draft Published http://www.w3.org/News/2013.html#entry-9756 The W3C validator http://validator.w3.org was updated last week to support the longdesc attribute as specified in http://www.w3.org/TR/html-longdesc/ Innovative browser vendors provide ways that make longdesc discoverable: http://www.d.umn.edu/~lcarlson/research/ld-ua.html Please fix this bug. Thank you.

> longdesc is a valid HTML5 attribute. " User agents should make the link available to all users through the regular user interface. User agents should expose the link to relevant APIs, especially accessibility-oriented APIs. User agents should enable users to discover when images in a page contain a long description. " 3. The longdesc attribute http://www.w3.org/TR/2013/WD-html-longdesc-20130312/#longdesc

longdesc="" is obsolete, it was removed from HTML for very good reasons. That there are people in the W3C who think otherwise is not news, but it doesn't make it part of HTML again. As the one who originally reported this bug, I'm marking it WONTFIX.

(In reply to Hixie (not reading bugmail) from comment #95) > longdesc="" is obsolete, it was removed from HTML for very good reasons. > That there are people in the W3C who think otherwise is not news, but it > doesn't make it part of HTML again. > > As the one who originally reported this bug, I'm marking it WONTFIX. Like it or not Ian while longdesc is obsolete in the whatwg spec it is no longer obsolete in HTML , while I personally agree that there are good reasons for it being obsolete as currently implemented in browsers, others do not and there has recently been new implementations of it, in NVDA (for example). I consider that one of the main failings of longdesc is that it has only been implemented in the accessibility layer, if it is the case that browser vendors can be pursuaded to implement a UI for it that exposes the feature to any user then I suggest it would improve it. Mozilla acc engineers have recently indicated they are willing to discuss the idea. For anyone intersted in pursuing this, i suggest a talk to dave bolter etal and open in new bug.

(In reply to steve faulkner from comment #96) > (In reply to Hixie (not reading bugmail) from comment #95) > > longdesc="" is obsolete, it was removed from HTML for very good reasons. > > That there are people in the W3C who think otherwise is not news, but it > > doesn't make it part of HTML again. > > > > As the one who originally reported this bug, I'm marking it WONTFIX. > > Like it or not Ian while longdesc is obsolete in the whatwg spec it is no > longer obsolete in HTML , while I personally agree that there are good > reasons for it being obsolete as currently implemented in browsers, others > do not and there has recently been new implementations of it, in NVDA (for > example). I consider that one of the main failings of longdesc is that it > has only been implemented in the accessibility layer, if it is the case that > browser vendors can be pursuaded to implement a UI for it that exposes the > feature to any user then I suggest it would improve it. Mozilla acc > engineers have recently indicated they are willing to discuss the idea. For > anyone intersted in pursuing this, i suggest a talk to dave bolter etal and > open in new bug. Thanks Steve. I opened a new bug: https://bugzilla.mozilla.org/show_bug.cgi?id=854848

Perhaps it's time to take a step back and look at the point of all this? The smart and talented people who write the specs (W3C or WhatWG) make choices about what does (or doesn't) go into those specifications. The thing is that those choices often directly impact the lives of people, most of whom don't know what HTML is, may not even understand what a browser is, let alone care. In this case the choice is simple: Do we give people a way to enjoy complex images, even when they can't access the original image itself? We've argued about longdesc for a long time, and I really don't think anyone really wants to go through all that again. It isn't a perfect solution, but it's the best damn thing we've got at the moment. So can we put some of the great ideas in this bug to good use, and solve a problem that makes a big difference to a lot of people who use this browser?