This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
SUMMARY * a new attribute: @desclink ("description link") * contains: URI * for: img, embed, object, video, audio, iframe, canvas, figure * purpose: to offer a link to a description of the embedded resource or figure; NOTE: a <figure> may have role=img. In that case, an anchor elment inside the <figure> elment would not be treated as a link by ARIA-supporting AT. Therefore @desclink would be useful for <figure>. A figure might also be reused in many contexts, the same way as an image might be reused, which is another reason why a central description might exist and might be useful - hence @desclink would be useful. RATIONALE * all uses and in particular AT users sometimes need in depth descriptions of resources that are inaccessible to them * any embedded resource could need a programmatically associated link to a relevant description * today there is no global, programmatic way to link to descriptions (the current solution, @longdesc, is limited to img and iframe) * that the attribute's name should be clear and telling (the name of the current solution, @longdesc, may have contributed to misuse and misunderstanding) * that a description link may be used even when the element is wrapped in an anchor element; * user choice: unlike for @alt and the @aria-* attributes, a link is optional to follow * that the description may contain markup (in contrast to @aria-describedby, which is presented as "plain text" to the user) * a description might be - but need not be - somewhat context independent (in contrast, anchor links are typically understood as directly related to the context) * by understanding the general description of the object, the user will be in better possition to understand the concrete use of the object Pros: * @longdesc without the misuse and misunderstanding that is associated with @longdesc * @longdesc without its limitation to the <img> and <iframe> elments only * @desclink (description link) is an easier to understand name than @longdesc * @desclink would not conflict with a possible <a> wrapper * an attribute is a very strong programatical association (in contrast, a wrapper element has a little bit weaker association) Cons: * can only be used for elements in the XHTML namespace. (in contrast, a designated element wrapper (bug 10938) with a desription link attribute could also be wrapped around foreign namespaces elements, such as <math> and <svg>) * just as for @longdesc, there is no way for the author to govern the link text: the description announcement text must thus be programmed into the reader - this has issues w.r.t. internationalization etc. Perhaps it could also affect the speed at which the feature is added to AT. * to reuse an existing attribute (@longdesc or @href) would probably have had better AT compatibility, but is not possible, AFAICT. (Such resuse would probably be possible/simpler if the attribute had been added to a new description link element - see bug 10938)
(In reply to comment #0) > (the name of the current solution, @longdesc, may have > contributed to misuse and misunderstanding) I see no particular reason this is the case. While a small number of the @longdesc errors were people writing the description inline, the majority of them were just bad urls. It seems that @desclink would be vulnerable to the same mistakes.
(In reply to comment #1) > (In reply to comment #0) > > (the name of the current solution, @longdesc, may have > > contributed to misuse and misunderstanding) > > I see no particular reason this is the case. While a small number of the > @longdesc errors were people writing the description inline, the majority of > them were just bad urls. It seems that @desclink would be vulnerable to the > same mistakes. Could you please describe the difference between "description" as @longdesc value and "bad urls"?
(In reply to comment #1) When I said "misunderstanding" and "misuse", then I include well intended as well as willful misuse. There is no doubt that there exists misunderstanding and misuse of @longdesc. The question is whether the name has contributed and if a new, better, name would help. Tantek Çelik's comment in the Poll seems to imply htat he think that a better name could have helped: ]] It is VERY poorly named - seems to imply a "long description" as even this survey misstates it whereas it is actually a URL [[. Mark Pilgrim's 'The longdesc lottery' classifies 96% of @longdesc instances as "obvious errors". He covered both invalid URLs as well as valid but meaningless URLs in that class. That is: he placed "description inline" amongst the 96% "obvious errors" class. Of the remaining 4%, he found 75% to be unobvious errors: "links to other images, links gone 404, links to one-line text descriptions identical to the alt attribute, and links to pages that describe the image size but not its contents (Wikipedia, I'm looking at you)". When it comes to "links to other images", then that is a category that might even have increased the last years. Just consider www.addfullsize.com. The addfullsize developer even argued with me on Twitter that @longdesc was the closest attribute he could find, and refused to change it. But AddFullsize.com is not alone in its misuse of @longdesc. Just consider google codesearch, which uncovers lots of meaningless top level domain URLs as well: http://www.google.com/codesearch?&q=longdesc%3D.*%5C.%5B%5Epjg%5D%5B%5Epni%5D%5B%5Efg%5D As for invalid URLs due to content being a text string, then the popular open source app, Gallery, had that error, until it was fixed some time in the summer of 2007 (but the error could still be deployed). Both you and Mark Pilgrim seem to operate from the assumption that everyone that have used @longdesc have understood its purpose but failed to use it correctly. Quoting Mark: ]] No more than one in a hundred get it right, of one in a thousand that even try. [[ However, evidence shows that authors make their own interpretation - well intended or bad intended. I agree with Tantek that the name could be be a factor. And new name should be so good and clear that it would remove any opportunity for doubt and well intended reintepretation, as well as being so clear that willful rereading of the attribute semantics would be difficult for authors who want to be "in good standing". But the name is of course not everything. The fact that @longdesc is linked to the @img element, instead of being a general attribute for embedded content, has probably contributed to misuse as well, simply because the need to show an alternative, often bigger size, verison of the IMG is so common. Also, I think that it is unfortunate that @longdesc has been linked to the issue of correct use of @alt - as we know, authors sometimes consider @alt as a purely a validation burdon. Authors might have added @longdesc just to be on the safe side, just as some authors - for sure - have added empty as well as non-empty @alt-s, just to validate. A global @desclink for all embedding elements plus <figure>, would benefit from being decoupled from <img>. When it comes to the name @desclink then that name is already somewhat similar to D-link, which is considered the alternative to @longdesc. But I also think a new name could serve to mark that @desclink is intended to have a bit wider use than @longdesc has - we should not focus on it too much on it as as an accessibility feature in the narrow sense, but rather see it somewhat like @alt: it is a feature that might be particular useful to some, but which is actually useful to us all. This said: You are well come to support bug 10938 instead, where I suggest to use a new, dedicated wrapper element for for the purpose of description links, if you believe that that would lead to more correct use.
(In reply to comment #1) HTML5 would offer 2 additional things that could make @desclink more successful than @longdesc 1) URL validation: validator.nu based HTML5 validation performs URL validity checking. This would at the very least catch invalid URLs. If we wish, we also have opportunity to make some of the urls in the 'obvious errors' category invalid. 2) @data-* The @data-* attribute can be used for the purposes that e.g. the AddFullisize.com developer misuses @longdesc for. (In fact, the AddFullsize.com developer has already told me that he intends to do that in his next version.)
Seems to me this is just requesting longdesc by another name, same as bug 10455. Therefore, assigning to Paul to hold on behalf of the chairs for the same reason as bug 10455.
(In reply to comment #5) > Seems to me this is just requesting longdesc by another name, same as bug 10455. I reject that interpretation. A more relevant context: ]] Surely we should have a) short alternative text for the audio/video b) a link to a transcript c) a link to a long description [[ See: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10642#c39 > Therefore, assigning to Paul to hold on behalf of the chairs for the > same reason as bug 10455. Unless you can describe to me an advantage of being assigned to Paul instead of Ian, then I reject that. Just because this bug could also solve the @longdesc issue, does not mean they are the same thing. For example, even if the outcome of ISSUE-41 could offer a solution to ISSUE-120, they are still different issues. Btw, I have also filed bug 10434 (rel=longdesc) - and that bug stands on its own feet, despite its clear link to @longdesc. Bug 10434 even predates bug 10455 - bug desite that, you did not link 10455 to 10434. For the record, I have not heard any support from Laura (reporter of bug 10455) for @desclink - it would be interesting to hear her opinion. From my perspective, solving this bug could also solve @longdesc issue as well. But I don't know if if anyone agrees. (You yourself is the best indication that I have that this bug *could* solve both issues.) But the opposite, getting @longdesc back for the IMG elment, would not be an acceptable solution to *this* bug. And neither would a globalized attribute with the name "longdesc" be either. (Well, in theory a globalized @longdesc could work, however, I have filed this bug in the belief that a new name would be better - including that I have concrete indication that the direction of *this* bug could have a higher chance for vendor support than simply reusing @longdesc.
Bug triage sub-team thinks this is a A11Y TF priority because it's related to longdesc (ISSUE-30 http://www.w3.org/html/wg/tracker/issues/30). Adding dependency on 10455 to reflect this, and TrackerIssue keyword to reflect relationship to ISSUE-30. Note the ultimate engineering of longdesc solutions may or may not support the suggestion in this bug, so this will have to be addressed when longdesc is complete.
This bug is directly related to Issue-30: http://www.w3.org/html/wg/tracker/issues/30 The HTML WG co-chairs believe that this bug has been addressed by the WG's decision on ISSUE-30. /paulc on behalf of the HTML WG co-chairs
mass-move component to LC1