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

(Snipping and summarizing liberally for contextual replies.)

I'm not trying to re-hash the longdesc thread that has been burning for years and, as I mentioned, I am not planning to file a formal objection, but I could not remain silent because, as Steve's original email stated:

>>> Silence will be taken to mean there is no objection


However, I will respond to your points inline.


On Nov 27, 2012, at 4:50 AM, Charles McCathie Nevile <chaals@yandex-team.ru> wrote:

> You might also find the discussion in the thread "longdesc as #id" illuminating

I am aware that longdesc can link to an in-page id, but if it's in page (as to a footnote detailing the table data of a rendered chart), I believe it should use a link accessible by anyone. If it's not something like a footnote intended for everyone, but it's truly at alternate of the content displayed in the image, then the embedded content should maintain its own accessible alternative, as demonstrated in the SVG+ARIA example.

>> [the publisher's association] 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.

Standard links and iframes both handle off-page resources in a way that all users can access. 

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

If you're talking about @aria-describedat, I'm not a fan of that proposal either.

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

Agreed.

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

I think you're missing my point. If an e-book reader unexpectedly navigates to a view that is not within the normal reading flow of a book, it may get into a UI blocking state for the user, where there is no way to navigate back or out. My point is that this would require special and separate UI specifically on behalf of the hosting application for AT users, that is not controlled by the AT. As history has shown, these separate interfaces are rarely equal.

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

Okay. I retract the presumption about the design effort.

> [new features take years or decades to implement] 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.

That's fine. As I mentioned, I am not planning to file a formal objection, but I could not remain silent because, as Steve's original email stated:

>>> Silence will be taken to mean there is no objection


Cheers,
James

Received on Tuesday, 27 November 2012 22:46:32 UTC