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