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

Re: My case for the obsoletion of longdesc (Was: 48-Hour Consensus Call: InstateLongdesc CP Update)

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 25 Sep 2012 03:58:04 +0200
To: James Craig <jcraig@apple.com>, John Foliot <john@foliot.ca>
Cc: "public-html-a11y@w3.org Task Force" <public-html-a11y@w3.org>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Message-ID: <20120925035804567991.905a8864@xn--mlform-iua.no>
James Craig, Mon, 24 Sep 2012 17:23:26 -0700:
> On Sep 17, 2012, at 1:56 AM, Leif Halvard Silli wrote:

> It would seem you’re concerned that activating a link in an iframe 
> would default the frame target to itself.

And about tabbing off behind the image, as John described. [0] 

> That's a valid concern, but 
> may not be a problem in practice, and there are ways to prevent that 
> accidental behavior. The author could use a target attribute, the 
> user could trigger a "open in new tab" functionality, etc.

You, the iframe champion, ought to have known that (when implemented,) 
iframe's seamless attribute could be used: [1]

]] this will cause links to open in the parent browsing context
  unless an explicit self-navigation override is used (target="_self")[[

With @seamless, then AT probably ought to not announce that it is a 
iframe, which sounds like an advantage to me. (But I might be taking my 
mouth to full, there, about how AT will react to it.)

> It may 
> also be appropriate for this page to open links in the same target. 
> In any case, it's something to consider, but I don't think it'd be a 
> concern, so to speak.

I suspect that your lack of concern is not simply because you "believe" 
in iframe but also because you view the case for long descriptions, as 
such, as less important. This is follows implicitly from your focus on 
new and improved techniques - accessible SVG and all that. Thus, it is 
a priority assessment. In combination with a "but it will not be a 
problem in practice" standpoint. Thus, you see 'iframe' and 'longdesc' 
as more ore less 'equally bad', except that iframe has wider support. 
You probably do not expect iframe to be much used either, I suspect-

David took a another attitude, I feel: [3]

]] It even strikes me that Someone With Skills could even make an
   iframe that looks like it lives on the back of the image, with
   the description contents, using JS, CSS, HTML, etc. :-), as an
   experiment. [[

So I would recommend giving the issue a little higher focus. E.g. you 
yourself have said that the iframe technique was described in A11Y 
authoring guides. And I personally would find it interesting if the 
HTMLwg produced as text about how to provide long descriptions - in the 
most optimal way - with other techniques than longdesc. For example, 
how to best use <iframe> for that purpose. Because, as I see it, to use 
iframe, requires both attention to the very iframe attribute as well as 
to the content one places there. And from one angle, I think that this 
need for more attention, could be an advantage - to the endusers. 
Because it can be all to simple to just provide a (longdesc) link, and 
hope that the user will be able to open it and navigate to the relevant 
part of that page. What I mean is: Even the resources that longdesc 
points to should be authored to function well.

[0] http://www.w3.org/mid/006f01cd9ab9$59e2b770$0da82650$@ca

[1] http://dev.w3.org/html5/spec/the-iframe-element#attr-iframe-seamless

[2] http://www.w3.org/mid/05B67D3F-00A1-448B-BB0A-F4B7BD47E192@apple.com

-- 
leif halvard silli
Received on Tuesday, 25 September 2012 02:00:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 25 September 2012 02:00:41 GMT