This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 3 http://www.w3.org/TR/2013/WD-html-longdesc-20130312/#longdesc "If a longdesc attribute has invalid content, user agents may make that content available to the user. This is because a common authoring error is to include the text of a description, instead of the URL of a description, as the value of the attribute." Allowing authors to include the text of a description rather than a URL can lead to significant issues for non-English text. User agents SHOULD NOT make this information available. Authors SHOULD learn to do it right. Otherwise: 1. authors may persist in misusing the attribute to the point that someone needs to pave the cowpath and issues an extension that allows user readable content in the longdesc attribute. 2. user readable content in attributes cannot be marked up for bidirectional text, language, or styling. Nor is it easy to indicate whether such text is intended to be translated, or not, for machines or translators. It should therefore be avoided where possible. (It's a bad enough situation to still have things like alt and title lying around, let's not make it worse, especially with a feature that encourages long, rich text content.) (Sent on behalf of the i18n WG after discussion.)
There is a tension between useful repairs and long-term encouragement. I am working on a browser extension that identifies non URLs and converts them to data URLs, because this will provide users with access to descriptions that might be useful. I believe this will lead to a significant improvement in accessibility for actual users, although I understand the principle that I am thereby solving a problem in a way that may lead authors to stop worrying about fixing it. Based on the heriarchy of needs principle, I believe the correct solution is still to allow user agents to make this repair, Validators SHOULD report when the attribute is incorrect (and accessibility testing should obviously include this simple validation as well as more). On the other hand, I think an implicit use case and requirement (i.e. they have somehow not been put into the spec) is to provide support for localisation of descriptions. Using HTML content (whether in the page or externally) can achieve this, and I think it should be explicitly noted. I'd welcome suggestions on this (you may want to raise a new bug). I also invite you to review the editor's draft, which has been updated.
+1 to the concerns from the i18n WG. (In reply to comment #1) > Based on the heriarchy of needs principle, I believe the correct solution is > still to allow user agents to make this repair, Regarding the needs: does this permission help those that needs it because the current instances of such invalid longdesc usage actually contains *useful* content? Can you show is any such useful content? (Btw, we both commented a Norwegian article about http://nrk.no, where the the responsible at NRK came forward an said that their useless longdesc usage relatedd to bad templates. http://www.epinova.no//blog/george-gooding/dates/2013/4/semantisk-bilde-html/#comment3366 ) My (well known) counter argumetns to what you say: 1. Today, the longdesc attributes in question, does not whether harm or help anyone, since no AT or browser suppor such repair. This is similar to how content of the (no obsolete, anyway) @summary attribute is ignored if the <table> is deemed by the assistive technology to be a layout [aka presentational] table). 2. Assuming thos most of the invalid longdesc attribute content is useless (if evaluated as long descriptions [e.g. because the same content is found elsehwere on the same page, which often seems to be the case]), one could say that having assistive technology *ignore* such content (as they do today) will function as barrier against experiencing the bad effects of the (sorry to use that word again) "longdesc lottery". 3. Which, in turn, probably will be positive when it comes to the willingness by vendors and longdesc critical people to acctuallly support this specification.
The "may" statement has been removed, the Task Force decided not to recommend a "should not" statement for repairing, based on the "heirarchy of needs" principle quoted below.
Perhaps the i18n IG and Charles could consider this: While I stand on i18n’s side, still, in the 11th comment in bug 21439, I hinted that fixing could be fully permitted provided that the bar is high enough. And the URL standard defines such a bar - namely, URL parsing failure. See: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21439#c11 If I understand the URL standard correctly, then, for longdesc="foo bar baz" the spaces would *not* cause a parsing failure, but would instead pass/parse as a URL. By formally allowing such fixing to take place, but only with a very high bar, we may gain better interoperability with regard to when it (by default) is permitted as well as with regard to how it is perfomed when it (by default or by user preference) is performed. I also think that this bar is so high, that the MAY could be fully justified.
For the record, the i18n WG is satisfied with the current spec text. Thank you.