- From: James Craig <jcraig@apple.com>
- Date: Tue, 26 Aug 2014 11:46:30 -0700
- To: Janina Sajka <janina@rednote.net>
- Cc: Charles McCathie Nevile <chaals@yandex-team.ru>, Joanmarie Diggs <jdiggs@igalia.com>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
On Aug 26, 2014, at 10:53 AM, Janina Sajka <janina@rednote.net> wrote: > Please correct me if I'm wrong, but my understanding is that the long desc spec, as currently in CR, would accomodate implementations that expose longdesc in iframes. As I understand it, a user agent that did that would be conforming. I suppose it would. > But, the spec does not compell iframes as the only allowable implementation mechanism, as James apparently wants us to do. I'm seriously flabbergasted. How did you come to the conclusion that's what I wanted? All of the recommendations at <http://cookiecrook.com/longdesc/> are intended to be author techniques; a complete replacement of longdesc, not implementation designs. > For my own part I think this illustrates a confusion between means and ends. Quoting myself from earlier in this thread in the hopes it will clear up some of this confusion: >> For most situations, I recommend the <details>/<summary> technique which is even backwards-compatible with text-only browsers like Lynx, and is a better overall approach than the iframe technique. The iframe example only exists because several longdesc proponents insisted that the external bolt-on description was a requirement for legacy longdesc and "D link" content. A standard rendered link here is a better option [than longdesc or iframe] too, whether inside or outside of a <figcaption> element to associate it with the image. Cheers, James
Received on Tuesday, 26 August 2014 18:47:00 UTC