Re: Call for Consensus (CFC) to move forward the HTML5 Image Description Extension spec for publication (FPWD)

On Nov 20, 2012, at 4:15 AM, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> We are calling for consensus on the HTML5 Image Description Extension specification [1] We have asked for and received feedback on the specification from task force members.
> 
> The question we are asking task force members:  Is this specification ready to be put forward by the Task force to the HTML WG and the Protocols and Formats WG for consideration for publication as a first public working draft (FPWD)? Please note: As a Working Draft publication, the document does not need not be complete, to meet all technical requirements, or to have consensus on the contents. Silence will be taken to mean there is no objection, but positive responses are encouraged. If there are no objections by Thursday, November 29th (Close of business, or 23:59 Boston Time), this resolution will carry. 
> 
> Other considerations to note: 
> - As a First Public Working Draft, this publication will trigger patent policy review. 
> [1] http://dvcs.w3.org/hg/html-proposals/raw-file/4893614e89f2/longdesc1/longdesc.html

I do not currently plan to make any formal objection, but I need to go on record again as stating that I do not support longdesc, for the following reasons.

1. Longdesc uses an approach that is sometimes referred to as "separate but equal," meaning the alternative content is not stored with the media or the linking document, which IMO is a flawed design pattern, as these external resources often become stale and outdated, remaining separate but rarely equal.

2. Longdesc is frequently championed as needed by book publishers despite the lack of evidence that any major publisher implements longdesc in its catalogs. The single request quoted from the publishers association did not actually request retention of longdesc. It requested ~"longdesc or an equivalent feature" and since many of these equivalent features already exist in HTML 5, I'd prefer to leave the poorly-implemented, and IMO poorly-designed, longdesc marked as obsolete. I would be fine having longdesc as "obsolete but conforming" rather than non-conforming, which would result in validators issuing a warning rather than an error.

3. Longdesc is under-designed and under-specified with regards to how the URL is accessed in contexts other than standard web browsers. What happens when a longdesc URL is activated in a web view in an app context that does not expect the need for "back" buttons or tabs? What happens when a longdesc URL is activated in the context of a e-book such as EPUB, where the long description content is not available "on the Web" or within the normal reading flow of the book? These questions represent holes in the specification for a feature that was designed as a stop-gap measure more than a decade ago and has not been updated to resolved problems with modern content that are better addressed by other existing features like the IFRAME element, the FIGURE element, an authored Shadow DOM, or embedded accessibility such as SVG+ARIA.

Thanks,
James Craig

Received on Monday, 26 November 2012 18:52:14 UTC