W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2016

Re: objects as links

From: Michael A. Peters <mpeters@domblogger.net>
Date: Tue, 29 Nov 2016 07:00:53 -0800
To: w3c-wai-ig@w3.org
Message-ID: <f4a8be4c-4df0-bea2-9bab-0cf07b8d8eb9@domblogger.net>
On 11/28/2016 07:31 PM, chaals@yandex-team.ru wrote:
>
>
> 29.11.2016, 02:27, "Michael A. Peters" <mpeters@domblogger.net>:
>> 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
>
> In Chromium in CentOS? That seems at first glance like a bug in how the OS decides what is clickable - or perhaps a browser bug in platform integration.
>
>>>>  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.
>
> Still seems odd. It shouldn't be the div that is clickable, but the child or children of the link.

Code that triggers it in FireFox and Chromium

<html>
<head>
<title>test</title>
</head>
<body>
   <div style="width: 80%; margin: auto; background-color: peachpuff;">
     <header style="width: 100%;">
       <a href="http://www.google.com/">
         <img src="/banners/some_banner.jpg" alt="[demo]" 
style="display: block; margin: auto;" />
       </a>
     </header>
     <div id="content" style="background-color: aliceblue;">
       <h1>Heading</h1>
       <p>Some Stuff</p>
     </div>
   </div>
</body>
</html>

Without display:block; on the image - the content to the right is not 
clickable bit the banner also then doesn't center. With block display, 
the space to left and right of image (but still inside header) is seen 
as part of the link - and from a conceptual point of view I can't say 
that is wrong.

That's why I want a solution that makes the link a property of the image 
as that is what conceptually it is. But since the img tag doesn't have 
an href attribute, JS is required and that's where it seems to become an 
accessibility issue because keydown is different than click to the 
FireFox (and other) pop-up blocker.

*snip*
>>
>> 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.
>
> That's because you're trying to open a popup with javascript - i think that's expected behaviour, given that you're not using a real link.

Right, because the HTML specification does not allow the link to be a 
property of the object the user is interacting with, but instead 
requires that the link be a property of a parent of the object the user 
is interacting with.

Unfortunately the whitespace is also seen as a child of that parent, 
hence why I need JavaScript to do the right thing, but doing the right 
thing then reduces accessibility at least by every method I've tried.
Received on Tuesday, 29 November 2016 15:01:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 29 November 2016 15:01:25 UTC