- From: <chaals@yandex-team.ru>
- Date: Tue, 29 Nov 2016 01:56:15 +0100
- To: Michael A. Peters <mpeters@domblogger.net>, "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
Hi Michael, 29.11.2016, 01:13, "Michael A. Peters" <mpeters@domblogger.net>: > I'm thinking of images but I'm sure this isn't only an issue with image > links. Take the following HTML > > <div id="topbanner"> > <a href="https://example.org" target="_blank" title="Buy Stuff from > Example.Org"> > <img src="/banners/examplebanner.png" alt="[An example banner]" /> > </a> > </div> > > If #topbanner bad is wider than the image, a usability bug is > introduced. Because the image is a child of the anchor, the anchor is > not limited to physical screen space of the image and (at least in some > browsers) empty white space to the right and left of the image will > trigger the anchor. In which browsers does that happen? > This is a UX problem because it is not what users viewing the web page > expect. I think it's a bug, which is why people don't expect it to happen. The normal model would be that the child element, if clicked, becomes a link. So it's only the images, not the whitespace in the middle, that should be active. > Thinking of the banner in terms of objects, it makes more sense for the > link and target to be properties of the image itself rather than > properties of a parent of the image. e.g. > > <div id="topbanner"> > <img src="/banners/examplebanner.png" alt="[An example banner]" > title="Buy Stuff from Example.org" data-href="https://example.org" > data-target="_blank" /> > </div> > > Currently browsers won't know what to do with that, but CSS can change > the pointer and a JavaScript function attached to the onclick event > handler can perform the action. > > That solves the UX problem - clicking the white space to left or right > of the image no longer triggers the action, only clicking on the image > itself does. Why objects like image don't already have href and target > attributes I don't know, it seems more logical to me for the link and > target to be a property of the object that the user interacts with. This was proposed for XHTML 2, actually. > But anyway, doing that breaks tab browsing - tab skips over it. I > suppose tabindex and a listener for enter key press could be used, but > what's the best way with the least ambiguity to tell accessibility > software that the object opens up a link? role="link" Hacking this together is possible, but pretty complex. > Another solution I suppose is to put a container around the a object > that is exactly same width and height as the image so that it constrains > the a element on the screen, but that seems conceptually wrong even if > it works. It seems to me that the conceptually right method is for the > URI to be a property of the image object. The HTML Working Group likewise concluded this when they were working on XHTML 2. But I'm not sure that it's going to get traction - there are a lot of simple benefits to the a element as a link. cheers Chaals -- Charles McCathie Nevile - standards - Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Tuesday, 29 November 2016 00:56:53 UTC