This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10015 - longdesc URL checking
Summary: longdesc URL checking
Status: CLOSED INVALID
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Macintosh Mac System 9.x
: P2 normal
Target Milestone: LC
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/embedded...
Whiteboard:
Keywords:
Depends on:
Blocks: 24594
  Show dependency treegraph
 
Reported: 2010-06-25 21:15 UTC by Leif Halvard Silli
Modified: 2014-02-10 10:36 UTC (History)
8 users (show)

See Also:


Attachments

Description Leif Halvard Silli 2010-06-25 21:15:54 UTC
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.
Comment 1 Leif Halvard Silli 2010-06-25 22:27:15 UTC
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
Comment 2 Ian 'Hixie' Hickson 2010-08-16 22:25:18 UTC
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.
Comment 3 Leif Halvard Silli 2010-08-16 22:59:55 UTC
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
Comment 4 Ian 'Hixie' Hickson 2010-08-17 18:54:03 UTC
Please don't reopen unless the appeal succeeds.
Comment 5 Michael Cooper 2010-08-31 13:37:24 UTC
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.
Comment 6 Laura Carlson 2011-03-14 13:11:47 UTC
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.
Comment 7 Laura Carlson 2011-03-14 13:14:51 UTC
Reopening bug since Issue 30 has been reopened.
Comment 8 Sam Ruby 2011-03-15 01:51:44 UTC
(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.
Comment 9 Laura Carlson 2011-03-15 08:10:20 UTC
> 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?
Comment 10 steve faulkner 2014-02-10 09:59:14 UTC
cloning and closing here as this bug should be resolved in the img description spec