Also added to http://wiki.whatwg.org/wiki/RelExtensions

Jame Craig added rel="Longdesc" to the POSH section of Microformats.org

http://microformats.org/wiki/existing-rel-values#longdesc

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: no spec change
Rationale: Since this is registered in the appropriate places, there doesn't seem to be anything further to do until implementations are widespread.

(In reply to comment #3)
Getting rel="longdesc" into HTML5 sooner rather than later, could impact on the (final) outcome of ISSUE-30 in one way or another. I therefore open this issue again, offering more detailed description of how it should be implemented, hoping that you seen opening for getting into the spec now. That said: I hope that we discuss this issue in its own right - linking this issue to whether @longdesc gets into the spec or not, is not likely to produce an honest and productive debate of the features of rel="longdesc".


DETAILED rel="longdesc" PROPOSAL

PROBLEM:
HTML5 fails offer a link relation (also known as "link type") which

1. has the semantics "link to a long description in the WCAG sense" 
2. implies a programmatic association between such a link and the embedded content it links from

  The @longdesc (or @describedby - bug 10455) is useful and should be kept. However, @longdescs unique feature - that it doesn't create a regular link and thus doesn't "disturb" those that supposedly  don't need it - is also many times not an advantage: An author might actually *want* to create a link control that is visible/accessible for *all* users and  which has the same or simlar semantics as @longdesc as well as with same or similar user experience as @longdesc has. However, there is no feature for that in HTML5.  WCAG 2.0 describes how to use regular links for this purpose. However, the methods it proposes are - many of them - to be considered hacks. (See 


USE CASES:
* Data Visualization i.e. charts and graphs
* Diagrams
* Cartoons, drawings, illustrations,  etc
* When @longdesc would have been ideal, but doesn't work (either as replacement or complement to @longdesc)


PURPOSE:
The purpose of rel="longdesc"/rel="description" would be to make sure that plain old links can be used - better, easier and more flexible -  for the purpose of linking to a long description of the object that the link is visullay or programmatically connected to. It is an accommodation for blind and visually impaired. However, unlike @longdes, it it is also aimed at all other groups that could need  a long description in another format, and which also would like to know in advance, that it is a long description and also would like to know how long description links - compared with how other links works.  (Gregory Rosmaita mentioned viewing wide embedded images on small screens as one usecase - http://www.w3.org/Bugs/Public/show_bug.cgi?id=10455#c74)

The aim of the long description is to provide what the visual representation provides. But the aim is also to offer a way for anyone to "draw a link" between object and 'long description'.  Unlike (at least some interpretations of) HTML4' longdesc attribute, a rel="longdesc" link  can be used for sighted and non-sighted alike. However, @longdesc is meant to link to a resource that is related to the current article/page. It is not meant for linking  to a related article - in that case authors should rather another (or no) link type, together with some link text which says "read more on this subject in this related article".


FUNCTIONALITY & USAGE:
* The rel="longdesc" attribute can be placed  inside any link element (<link>, <area> or <a>), when the purpose of the link is to link to a long description of an embedded object.
* The link element with rel="longdesc" might be wrapped around the object, or adjacent to the object, or  placed in an image <map> element for the object be a child element of an <object> element. Thus there may or may not be a programmatic association between the link element and the object for which it points to a long descritpion. 
* When presenting the link to the user, the user agents should have the option to programmatically inform the user that it is a long description type of link, in such a way that the user both understands _that_ it is is a long description kind of link, and also understand what it is a long description for. (Much like for @longdesc today.)
* A user that is informed that the link is of type rel="longdesc", should be able to have a set of expectations about such links. E.g.  when clicking the link, the link should open in such a way that the current page is not simultaneously closed.  This could be achieved with an implicit target="_blank", whicih is the same method that is implemented for @longdesc. Or it could be achieved via some AJAX implemenation. The user can expect that the link points to a resource directly related/linked to - and crafted for - the current page, and which only points  to some related in-dept info specifically meant to be read, by those who want, in connection with the current page/article. (This link type should *not* be used to link to an article that merely *relates* to the current article, by being about the same subjecto or something like that.) 
* A rel="longdesc" link should be able to point to a document containing both images and text, provided that the images are of role="presentation" *and* contains a real, long description.
* To allow easy hiding of rel="longdesc" links from visual display ("due to the marketing departement's requirements"),  it should be considered whether the link text of rel="longdesc" links can be permitted to be empty, in which case it should be autogenerated by AT (or via CSS), much the same way that e.g. Jaws generates "Press enter for long description" whenever there is a @longdesc.
* Links of rel="longdesc" type SHOULD  be revealed when using keyboard navigation.
* The functionality should also offer good fallback when the user agent does not have any support for this link type. Therefore, in order to ensure good fallback, and in addtion to a description of how user agents should implement rel="Longdesc",  we should also describe how authors can implement the expected rel="longdesc" behavior. Keywords are: use of rel="longdesc", use of target="_blank", use of CSS generated content (if there is no link text is empty) and so on and so forth. 
* A link with rel="longdesc" should "live in the same namespace" as @longdesc. Thus, when the mark-up makes it clear (e.g. via @role="img" on a wrapper element) that they are point to a long description for the same thing,  then an AT which supports both @longdesc and @rel="longdesc", should probably give preference to the rel="longdesc" - or at least seek to filter out the one or the other. Thus it if an <img> is wrapped inside a anchor element with rel="longdesc", the @longdesc should preferrably be ignored - both to avoid duplication and in case there they point to different resources. Instead the rel="longdesc" link should be treated lik a @longdesc lik by the AT.
* Authors SHOULD NOT use 1 pixel images wrapped inside a rel="longdesc" link as a method for hiding the rel="longdesc" link. Avoidance of that hackish method, which never the less is described by WCAG 2.0 Technique G73, is one of the reasons for the establishment of the rel="longdesc" link type.
* Finally, rel="longdesc" is likely to draw attention to this subject, and thus create consciousness about the problem 'how to link to a long description', including taht it would allow authors to become creative about how to solve the problem.


LINKING METHODS - HTML5 vs WCAG2.
  There are 4 relevant ways to use links with the purpose of linking to a long description. However, WCAG 2.0 only offer a description of one of them - adjacent links - as well as of a fift method: @longdesc:
1.  a link adjacent to the object. Also known as "description links" in
      WCAG 2.0 Technique G73: http://www.w3.org/TR/WCAG20-HTML-TECHS/G73
2.  a link wrapped around the image/object. WCAG 2.0's only discusses this option
     for the usecase when an image funcitons as a link to another resource - it does
     not discuss it as an option for providing an longer description
3.  an image map to create an association between object and link(s) 
     Image maps is actually a special case of adjacent links
4.  a link that is located inside the fallback of the object,
     e.g. if one is using the <object> element.
     A link inside an object works pretty much like a @longdesc link as it
     doesnt attract attention (not even a 'link stop' when using keyboard
     navigation) from sighted userse
5. longdesc is WCAG 2.0 Technique H45: 
     http://www.w3.org/TR/WCAG20-HTML-TECHS/H45


DESCRIPTION LINK PROBLEMS - GENERAL
  All the above solutions (except the @longdesc attribute, of course) share the problem that it might be difficult for the user to know that the link actually leads to a long description resource. This is a a problem for all users. However, for a non-sighted user, this might be even more difficult to know.  Thus all of the above linking methods  could benefit from a rel="longdesc" link type.

Some of the 5 options above, might/may have been considered (by the WCAG 2.0 authors) to be more difficult to use for long descriptino purposes than others. E.g the reason why a link wrapper is not discussed by WCAG 2.0 Techniques at all, is probably because it is hard for a blind user to know whether the image is a "image link", or whether it serves as an image enlargement button  or (not so often) if  points to a long description. (Of course, it might also be because describing such a method would compete with @longdesc.)

Some of the solutions suggested in G73 can be described as hacks. It involves placing the link immediately adjactent to the embedded resource, hiding the link in a very small image (1pixel wide et cetera), using a specific link text ("Long description of this resource") or using the anchor element as a (visible) caption for the embedded resource, with information about the purpose of the link inside the @title attribute.


DESCRIPTION LINK PROBLEMS - SPECIFIC
  * Simply placing the link nearby the embedded resource does not always make the relationship clear - thus it should be possible to wrap the link around an object, in order to draw a stronger connection, without risking confusing the user.
  * However, when an object is  wrapped inside an anchor element, then it can be hard for a screenreader user to know whether the link points to a description of the <img>, or whether the @alt text of the <img> is meant as link text.
  * When using an invisible/small <img> elment as link text container, then what ARIA @role should the <img> element then have? Even if a suitable @role can be found, it seems backwards to FIRST hide the link's visibility from sighted user. AND THEN hide the fact that it is an image from the non-sighted users via ARIA. 
  * Links might also be hidden via CSS. But regardles of how the link is hidden, when navigating from link to link via the keyboard, such a link creates a "stop", without any obvious purpose, for the sighted users (See Benjamin Hawkes-Lewis comment 48 in bug 10455  http://www.w3.org/Bugs/Public/show_bug.cgi?id=10455#c48). @longdesc offers a solution to this problem (it is unavaiable to keyboard navigation), as does links inside the <object> element (links inside an object element are also not available to keyboar navigation, as long as the embedded resource of the object is available).
  * Asking authors to use a standardized text such as "Long description of resource X" - if the text is supposed to be possibel to standardize, then perhaps it would be more accessible and more language independent to allow user agents and CSS to generate it? An anchor element without visible content would also be simpler to hide. The content could be made visible when the element has focus.
  * @longdesc is a good feature, but not even all screen readers support it. It is unfortunate if authors, when they are looking for the semantics which @longdesc posesses, are only able to choose a single feature - which doesn't work universially. It is also unfortunate, should they choose to duplicate the @longdesc as a link, that the link doesn't have the same semantics, In the latter case,  it would also lead to annoying llink duplication, should the user agent happen to support @longdesc.


HOW REL=LONGDESC  COULD BRING ENHANCEMENT:
  There is no perfect solution for all situations. Authors must continue to use all the methos described above. However, for all of the 4 ways one may use a link, the rel="longdesc" offers an enhancement: it gives the user agent the possibility of notifying the user that a certain link is a longdesc link, and thus create expectations for the user about how such links are implemented in his/her browser. In particular, @rel="longdesc" offer a benefit for images that are wrapped in a link and for image maps - these methods are not recommeded/described as solution by WCAG 2.0 today, Thus, the most important benefit of rel="longdesc", is that it allows authors to take into use a wider arsenal links, including links that are programmatically associated with the object. Using Object elemetns instead of <img>, or using image map, may have its problems and may be considered difficult to use by many authors. However, HTML5 should provide the necesary means for those that want to put even take those methods into use.

A rel="longdesc" link may also have one particular feature which perhaps now and then is an advantage against @longdesc: for a visited links, a screenreader informs that the link has been visited, whereas a for a @longdesc link, I don't believe that they offer such information. (At least JAWS did not seem to do that, when I tested it.) Another advantage over @longdesc, when the rel="longdesc" link is placed inside the fallback of an <object>, is that whether it is visible/available to the user depends on the media type: in textual browsers, the link in the fallback will be visible - the same should be the case for screenreader. Whereas in a GUI browser, it will be hidden.

FINALLY: @longdesc VERSUS rel="longdesc"
  The two solutions would certainly compete with each others. But it would be a good competition. Currently, @longdesc is not a success - it is often misunderstood by authors and often "mystified". By specifiying how one can recreate the *semantics* of @longdesc as a link, authors would also gain better understanding for how @longdesc works, which again could make it more popular.

DETAILED rel="longdesc" PROPOSAL - continued:


Screenreaders versus the title attribute:
Screenreaders software is known for not making the content of the @title attribute known to the user. 
See research by Steven Faulkner: http://www.paciellogroup.com/resources/articles/WE05/forms.html

Thus, providing the purpose in the @title attribute (as WCAG 2.0 technique G73 recommendes,  while possibly being useful to many users,  may not help that particular user group.

@rel="longdescc" could provide the screenreader software with an opportunity to announce the link as a long description kind of link.

The problem isn't lack of documentation, it's lack of implementation experience and implementation commitment.

Bug triage sub-team thinks this is a HTML A11Y TF priority because of relationship to longdesc. Adding a11ytf keyword. Not sure this is a longdesc solution, but needs to be considered and either supported or opposed in context of the overall longdesc strategy.

Note there is a catch 22 between relying on browser support before the spec states a solution, and browsers waiting on spec before they implement anything.