10015 2010-06-25 21:15:54 +0000 longdesc URL checking 2014-02-10 10:36:53 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified Macintosh Mac System 9.x CLOSED INVALID http://dev.w3.org/html5/spec/embedded-content-1.html#the-img-element P2 normal LC 24594 1 xn--mlform-iua ian faulkner.steve ian laura.lee.carlson mike public-html-admin public-html-wg-issue-tracking rubys xn--mlform-iua public-html-bugzilla oldest_to_newest 36423 0 xn--mlform-iua 2010-06-25 21:15:54 +0000 Probably as consequence of @longdesc having status as obsolete and non-conforming, Validator.nu does not perform any validity checking of th longdesc URL. Thus authors are not told whether they used it correctly or not - all they get to know is that it is wrong to use it. HTML4 did not perform URL validity checking. And in the case of @longdesc, this has probly contributed a lot to the lack of understanding of how it works. Meaningless or invalid URLs represents 96% of all errors linked to @longdesc. See Mark Pilgrim's blog post: http://blog.whatwg.org/the-longdesc-lottery Hence introducing URL validity checking of @longdesc would be important. Do the maths: (A) making @longdesc invalid will lead to 100% of all longdesc occurences becoming stamped as errors. (B) making it _valid_, but with strict URL checking, could in theory lead to 96% of all @longdesc occurences stamped as error Hence we should perform proper URL validity checking rather than stamping all use as invalid - since this would in theory lead to the same error match. Criteria: Due to the problems with incorrect use, I suggest that longdesc URL checking should be stricter than the URL checking that Validator.nu performs with regard to validity of the URLs inside @src, @href, @cite etcetera. By stricter I mean that we should evaluate whether the things Mark Piligrim took up, should be invalid - or cause warning - in @longdesc, despite that it may not be considered an error to do the same in @src or @href: * the empty string * pointing to the same URL as the src attribute * pointing to the page you're already on * pointing to the root level of another domain (probably not possible to check) * is the same as a parent link's href attribute (i.e. the longdesc is redundant because you could just follow the image link instead) One could also consider showing warnings or errors if the longdesc URL has certain file endings, such as .gif, .jpeg etc One of Mark Piligrim's sources (http://wiki.whatwg.org/wiki/Longdesc_usage) showed that use of @longdesc as a word container is the largest group or errors: "12 pages used longdesc="..." not as an URL, but as a human-readable description" It should probably be considered an error to use @longdesc on a presentational image. Thus, if the <img> has an empty @alt, the user should see an error, since such an image would (probably) count as having role="presentation", meaning that AT users would not see it. 36425 1 xn--mlform-iua 2010-06-25 22:27:15 +0000 Validator should display warning if @aria-describedby and @longdesc are similar. Thus this should cause warning: <img aria-describedby=samepage-fragment longdesc=samepage-fragment src=foo alt="Foo. Bar."> While this should not: <img aria-describedby=samepage-fragment longdesc=#samepage-fragment src=foo alt="Foo. Bar."> (The longdesc is a URL and thus needs the to be a #fragment URI, if it points to the same pager, while aria-describedby is a idref.i 37522 2 ian 2010-08-16 22:25:18 +0000 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: Rejected Change Description: no spec change Rationale: The longdesc="" attribute is obsolete, per WG decision. 37528 3 xn--mlform-iua 2010-08-16 22:59:55 +0000 ISSUE-30 has been appealed, and the Appeal is awaiting response from the Team Contact and/or Director. http://www.w3.org/mid/20100815024127561631.58433bf1@xn--mlform-iua.no 37572 4 ian 2010-08-17 18:54:03 +0000 Please don't reopen unless the appeal succeeds. 38310 5 cooper 2010-08-31 13:37:24 +0000 http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0013.html The bug triage sub-team thinks the HTML A11Y TF does not need to formally follow this bug. Original submitters or other interested parties may choose to continue to push this issue on their own. Notes from the sub-team may follow in a separate comment. 46673 6 laura.lee.carlson 2011-03-14 13:11:47 +0000 Enabling validators to programmatically detect improper URIs would help make longdesc more robust. More people use the W3C validator than read the specs. It has been said that the W3C HTML4 validator has done worlds more than the HTML4 specification for increasing the quality of HTML documents on the web. http://lists.w3.org/Archives/Public/public-html/2008Nov/0122.html Requiring longdesc link checking would also aid in accessibility education. http://validator.w3.org/docs/why.html#learning It would create a teachable moment. 46674 7 laura.lee.carlson 2011-03-14 13:14:51 +0000 Reopening bug since Issue 30 has been reopened. 46700 8 rubys 2011-03-15 01:51:44 +0000 (In reply to comment #7) > Reopening bug since Issue 30 has been reopened. Presumably, when Ian said "appeal succeeds", he was not referring to the intermediate step of the issue being reopened, but rather to the entire process. A status of OPEN means that the ball is in the editor's court. A status of RESOLVED coupled with TrackerIssue means that the ball is the WG's court. 46712 9 laura.lee.carlson 2011-03-15 08:10:20 +0000 > Presumably, when Ian said "appeal succeeds", he was not referring to the > intermediate step of the issue being reopened, but rather to the entire > process. Ian, Is that what you meant? 100118 10 faulkner.steve 2014-02-10 09:59:14 +0000 cloning and closing here as this bug should be resolved in the img description spec