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: James Craig <jcraig@apple.com>
Date: Mon, 24 Sep 2012 21:21:54 -0700
Cc: John Foliot <john@foliot.ca>, "public-html-a11y@w3.org Task Force" <public-html-a11y@w3.org>
Message-id: <5E9C2DA6-AB41-4EB4-A20B-7FBBFEA4F302@apple.com>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>

On Sep 24, 2012, at 6:58 PM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote:

> You, the iframe champion,

Champion is a strong title. I would say I created a proof-of-concept.

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

One of the goals of that proof-of-concept is to make it so that you don't have to access the "long description" unless you explicit drill into it, like @longdesc. Using @seamless would prevent that benefit to using an iframe.

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

That's a fair assessment.

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

All wise recommendations. I don't want to commit myself to creating a WCAG technique for iframe-linked long descriptions, because as you noted, I think this isn't a much better approach than @longdesc, but I would commit myself to review your forays into this technique if you felt inclined to create some.

Received on Tuesday, 25 September 2012 04:25:16 UTC

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