- From: Michael A. Peters <mpeters@domblogger.net>
- Date: Mon, 28 Nov 2016 17:19:30 -0800
- To: w3c-wai-ig@w3.org
On 11/28/2016 04:56 PM, chaals@yandex-team.ru wrote: > 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? FireFox current version running in CentOS and I believe also in Chromium > >> 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. The whitespace to the left and right of the image but still inside the parent container is clickable, but white space above and below the image is not. The scope of the anchor tag seems to be everything to the left of right of the child image within the anchor's parent tag. > >> 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. What I have tried is role=link and tabindex=0 along with a keydown event handler, but that triggers the FireFox popup blocker if the site isn't white-listed. The click event handler doesn't trigger it.
Received on Tuesday, 29 November 2016 01:20:02 UTC