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

Hi James,

chair hat off.

TL;DR: Yes, it is possible to do things better. But all such proposals  
have proven to be vapourware, or not actually better either through design  
flaws or because they failed to be as versatile as longdesc. longdesc is  
actually real and moving the spec forward seems valuable, although I would  
be perfectly content to see some better alternative overtake it in the  
market.

On Mon, 26 Nov 2012 22:51:44 +0400, James Craig <jcraig@apple.com> wrote:

> 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.
...
>> 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,

This is not true.

Please see the first example in the specification, and the final use case,  
which explicitly covers this case.

You might also find the discussion in the thread "longdesc as #id"  
illuminating - it shows that most early implementors of longdesc  
considered content in the page an obvious use case.

And anecdotally, among the hand-trawled collection of examples in the wild  
(warning - some of these are things people might find confronting - if you  
don't like the F-word, don't follow the link) are some that use this  
pattern: http://www.d.umn.edu/~lcarlson/research/ld.html#onpageanchor

A "nice" subset:
http://bembelterror.de/frankfurt/bday-2007
http://www.w3.org/WAI/PF/HTML/consensus-procedures
and the test cases for a 2005-2008 implementation as a firefox extension
http://www.splintered.co.uk/experiments/archives/firefox_longdesc_extension/#samepage

> which IMO is a flawed design pattern, as these external resources often  
> become stale and outdated, remaining separate but rarely equal.

Yes. But the issue of how well people maintain content is something we  
have limited ability to resolve. Were there a better alternative on offer  
I might find this argument less unconvincing.

> 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.

I have no special comment on this - it isn't one of the use cases which  
lead to requirements, just a generic functionality request.

> It requested ~"longdesc or an equivalent feature" and since many of
> these equivalent features already exist in HTML 5

It is possible, with various combinations of approach, to cover various  
combinations of the use cases. Much as I like the approach of the picture  
element, it fails to handle the important use case of content which is not  
on the same page. A development environment where there is thoughtful  
management of resources is typical in the sort of high-cost situations  
where people will spend the money to develop descriptions in the first  
place, and alternatives are the same design without the benefit of a  
simple standardised mechanism.

> I'd prefer to leave the poorly-implemented, and IMO poorly-designed,
> longdesc marked as obsolete.

Were there an effective replacement, I might agree with your conclusion,  
although I do not agree that it is poorly designed. Indeed, 7 years of  
argument from people who say it is poorly designed but offer something  
with the same design (the major improvement offered is a more generalised  
application of the design, the major different design only deals with more  
restricted use cases), but a different name confirms my belief that the  
design is pretty good at solving the requirements which follow from the  
use cases.

> 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.

Frankly, I'm all in favour of that - it is why I restricted the existing  
proposal to what has been implemented, basically for the img element. But  
it presupposes a better option, and "the same design with a new attribute  
name" doesn't strike me as an obvious improvement.

> 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?

Whatever happens with any linked content. This is not a new issue - the  
same problems occurred in the WAP walled gardens of the late 1990's, and  
people learned that a back button was not a bad geenric functionality.  
People who build apps with specific goals not to be an open web browser  
have the benefit of a decade and a bit of experience in dealing with this  
problem. One possible strategy is to open the description on deamnd in a  
"lightbox" - although there are other approaches and which one is chosen  
depends on the use case.

> 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?

The same thing that happens to any linked content which is developed in  
this context. It doesn't take a genius to use one of the 3 or 4 existing  
approaches to collecting resources required for offline use (widgets,  
JSON/zip packaging, appcache, authoring for the offline case, MHTML, "save  
with linked resources"...) that have been implemented repeatedly and  
successfully for years. When longdesc was being designed in the late 90s,  
I was using commercially available software like webgrinder (because I was  
too lazy to write my own) to distribute millions of CD-ROM versions of  
content that had been designed for the open web for places like Vietnam  
and outback Australia where connecting to the real web wasn't an option.  
This has been succesfully dealt with by all six browsers I have as  
quick-launching applications, and a great deal of other software. People  
working in this context have several different models to copy, most of  
them many years old.

> These questions represent holes in the specification for a feature that
> was designed as a stop-gap measure more than a decade ago

Is that an accurate representation of the design effort? My understanding  
is that the feature was designed to fulfil known needs. My experience is  
that although it is a difficult problem to solve, the solution they came  
up with does a reasonably good job compared to alternatives.

> 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.

I spent a significant amount of effort arguing the case for the modern  
design of ARIA that enabled it to be easily integrated with both HTML5 and  
SVG. Aaron Leventhal, Anne van Kesteren, Simon Pieters, Anders Markussen,  
and others I have unfortunately forgotten came up with the design, I just  
managed to convince people like the TAG that it made sense. I worked hard  
on shadow DOMs. I believe that these approaches could potentially offer  
something better than longdesc. But their deployment and implementation*  
half a decade later make longdesc look like a resounding market success  
and a de facto standard already - which makes me wonder why it isn't  
formalised, and led me to propose this extension.

cheers

Chaals

I note the outstanding work Apple shipped for SVG accessibility, only a  
decade after "Accessibility features of SVG" suggested it, as one of the  
leading efforts. If those are the timescales we are dealing with, let's  
ship the longdesc spec and get on with making the web better than that.

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Tuesday, 27 November 2012 12:50:46 UTC