Re: objects as links

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.

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

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.

> The click event handler doesn't trigger it.

Doesn't trigger the link function when you click, or when you try to do it with the keyboard? It's expected behaviour that without a keyboard handler, you don't get the same ability to use keyboard to trigger a click that you have with *known* interactive elements like links and buttons.

You could try using an accesskey and see what happens - I don't want to predict, but it would be useful to have some data…

cheers

-- 
Charles McCathie Nevile - standards - Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Tuesday, 29 November 2016 03:31:42 UTC