- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 15 Aug 2016 14:10:37 -0700
- To: "Patrick H. Lauke" <redux@splintered.co.uk>
- Cc: Doug Schepers <schepers@w3.org>, David Dailey <ddailey@zoominternet.net>, Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, Rich Morin <rdm@cfcl.com>, w3c-wai-ig@w3.org, Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>, www-svg <www-svg@w3.org>
On Sat, Aug 13, 2016 at 2:49 AM, Patrick H. Lauke <redux@splintered.co.uk> wrote: > On 13/08/2016 05:50, Doug Schepers wrote: >> I'd like to hear a more concrete explanation of why interactivity in >> <img> must be disallowed. > > > Maybe not a deeply technical explanation, but: I would argue that when > talking about an "image", people are thinking about something visual, > presentational, non-interactive (though possibly animated). The <img> > element is the HTML representation of this concept. In fact, the spec (for > convenience, just going to point to > https://www.w3.org/TR/html5/embedded-content-0.html#the-img-element) says > > "[...] a non-interactive, optionally animated, image resource that is > neither paged nor scripted." > > <img> is exposed to AT with a role of image, and again this is understood > (by users and AT) to be something non-interactive. > > *IF* you wanted to add something interactive inside an <img>, you'd need to > signal this with at least the addition of a different role="..." attribute > (and then change user agent behavior, which would assume <img> is > non-interactive, so presumably doesn't cater for focusability etc). But this > still feels like a conceptual stretch... Yup! And it's a completely *unnecessary* stretch, because HTML *already* has elements that indicate interactive embedding of resources: <iframe> and <object>! There's zero need to fiddle with <img>'s semantics. ~TJ
Received on Monday, 15 August 2016 21:11:39 UTC