W3C home > Mailing lists > Public > public-html-a11y@w3.org > November 2012

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

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Wed, 28 Nov 2012 04:10:50 +0400
To: "James Craig" <jcraig@apple.com>
Cc: "Steve Faulkner" <faulkner.steve@gmail.com>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Message-ID: <op.wogiscyly3oazb@dhcp-216-67-wifi.yandex.net>
Hi James,

chair hat off...

On Wed, 28 Nov 2012 02:08:01 +0400, James Craig <jcraig@apple.com> wrote:

> (Snipping and summarizing liberally for contextual replies.)

Fair enough.

> 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

Yeah, we as chairs should have said it means assent, or "I can live with  
it - but might not like it". I'll try to make sure we tighten that up in  
future, and if we slip, please call us on it again.

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

Sure. For many use cases that's the logical thing to do. I am in line with  
the NVDA guys - this should be a browser functionality, not something for  
AT to have to patch in. The implemntation in Opera (which pretty much  
copied iCab) and my extension for Opera were both based on that principle  

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

Totally agree. And serious props to you guys for making something real out  
of that, plus apologies for my unnecessarily snarky comment the first time  
around. But it won't readily retrofit into <img> as used on the Web for  
the last couple of decades.

That would need something like EXIF. Do you know the RDFPic stuff from  
about 10 years ago? It was an attempt to show that an approach like EXIF  
*could* work for img elements. It's a tough sell because it takes a  
serious change in tooling for producers and consumers. And the data is too  
often too hidden - and we know where that leads...

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

Yes, but you lose the association. For a back-end services provider like  
Yandex, that's a loss that's hard to make up algorithmically.

BTW I get the impression we're entirely on the same page about making the  
functionality available to all users.

>>> 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 guessed not. I think it is actually a useful idea - but while I am  
waiting to see if it goes anywhere, I'll run with getting a decent spec  
for what we have.

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

No, I don't think I did...

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

That depends on how you build your whole UI, but yes it can arise. Like  
early WAP browsers that didn't have back buttons (or allowed site authors  
to remove them).

> As history has shown, these separate interfaces are rarely equal.

And as history has shown, people aren't always good at learning from  
history. You are quite probably right that someone will make the same  
mistake again, despite the years of experience whose conclusions are  
readily available. Sadly, given that AT is often pretty slow-moving, the  
pain is likely to last longer than it would in a "mainstream" product  
(look at how accesskey implementations are allowed to suck for years on  
end for an example of what I mean).

But we already rely on common sense and market failure to weed out bad  
implementation, and I don't think the risk here is any higher than normal.

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

Fair enough.

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

(see the beginning)

I think we're closer than we might seem on this whole thing. I appreciate  
you taking the time to clarify your thoughts.



Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com
Received on Wednesday, 28 November 2012 00:11:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:32 UTC