Image block lightbox: do not overlay the image with a transparent button

[afercia]

Description

When an image block is set to open the image in the lightbox, a transparent button entirely overlays the image.

This button is necessary to open the modal dialog. However, it entirely overlays the image. With the current implementation I see a couple problems that I'd consider pretty serious.

1 The browsers contextual menu that opens on right-click is different depending on the browser in use.

This surprised me. I would have expected to always get the same contextual menu. I have no idea whether this is a browser bug or a 'feature'. Regardless:

• Chrome and Opera open the image contextual menu. This looks 'visually correct' but it's wrong, as the element that actually receives the right-click is the transparent button.
• Firefox and Safari open the button contextual menu. This looks 'visually wrong' but it is actually the correct behavior.

Regardless which browser is right and which one is wrong, the current implementation triggers a behavior that breaks am expected browsers feature. Also, the user experience is pretty confusing in at least two of the major browsers:

• As an user, I see a normal image.
• When right clicking, I would expect to be able to save the image, open it in a new tab, copy the image, etc.
• Instead, the browser contextual menu doesn't show me any of those commands.

2 There is no visual indication at all that the image can be enlarged in a modal dialog

Visually, the image with the lightbox looks exactly like a normal image. There's no visual indication or any other hint to communicate that the image can be clicked and enlarged in the lightbox. The only subtle visual indications are only visible when hovering or tabbing:

• Hovering: the mouse cursor changes to zoom-in.
• Tabbing: the focused 'image' (actually it's the button) shows a focus outline.

Seems to me both cases are insufficient indications.

• On mobile there is no hovering or tabbing. I wonder how users are supposed to understand the image can be enlarged.
• On mobile, users will likely think the image is a normal image. Potentially, they could trigger an unwanted click when scrolling the page and the lightbox would open unexpectedly.
• Also on desktop understanding the image is clickable is not trivial.
• Some users may use devices or assistive technologies that don't use hover or tabbing.
• The mouse cursor change is an unreliable indication as some users may have set a custom cursor at the operating system level.

Step-by-step reproduction instructions

• Add an image block and set it to open in the lightbox.
• Publish and view the front end.
• Test with macOS Chrome and Opera:
  • Right-click the 'image' (reminder that you are actually right-clicking the transparent button)
  • Observe the contextual menu that opens is the one related to the image.
• Test with macOS Firefox and Safari:
  • Right-click the 'image' (reminder that you are actually right-clicking the transparent button)
  • Observe the contextual menu that opens is the one related to the button.

Screenshots, screen recording, code snippet

In the screenshots below, I altered the transparent button to better illustrate the issue:

• I applied a semi-transparent red background to the button to make it visible while keeping the image visible.
• I shifted the button a little to the right and bottom, to be able to right-click the image behind the button.

macOS Chrome and Opera: right-click on the image shows the image contextual menu, as expected:

macOS Chrome and Opera: right-click on the button shows the image contextual menu, this is not expected:

macOS Firefox and Safari: right-click on the image shows the image contextual menu, as expected:

macOS Firefox and Safari: right-click on the button shows the button contextual menu, as expected:

Proposal

I'd think the simplest and most effective solution would be to just not entirely overlay the transparent button over the image. A visible button with an appropriate icon and labelling (preferably an icon + visible text for a11y reasons) would solve both issues:

• right clicking on the image would be consistent in all browsers
• there would be a clear, visible, indication that the image can be enlarged

I think a button in the top right is a pretty common pattern I've seen being used around on the web. Basically, a button placed in the red spot highlighted in the screenshot below:

Ideally, the buton should have visible text:

Enlarge {icon here}

In all cases, the button size should be at least 44 by 44 pixels.

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[afercia]

One more reason why overlaying the transparent button over the image is less than ideal, it's that there's no guarantee the image will be actually rendered with the same size of the figure element. Some themes do actually alter the original image size depending on the alignment settings.

For example, Twenty Sixteen does it. It uses negative margins. As such, the transparent button may overlay only a part of the image, so clicking on the rest of the visible image doesn't do anything. Other themes may do crazy things with images and seems to me there's absolutely no guarantee the button will overlay the image correctly.

In the screenshot below, I highlighted the transparent button with a red background and some opacity to better illustreate. - - Areas of the page that look empty but are actually clickable are very confusign and something we should really avoid.

• Areas of the image that are not clickable are confusing as well.

I think the positioning of the button would be way simpler and more reliable if it as just a normal button overlaid in one of the image corners.

Screenshot from Twenty Sixteen:

[afercia]

Overall, I think this is something that should be prioritized for the incoming release. Cc @annezazu for consideraing some high priority.

[afercia]

One more feature that will break with the lightbox is the image title attribute.

Although title attributes aren't great as they're only available to some users, the editor gives the ability to add a title attribute to images. The title attribute is expected to show on hover in a native browseer 'tooltip'.

Given the image is entirely overlaid with a transparent button, the actual hover happens on the button: browsers won't show any tooltip. To reproduce:

• Set an image block to open the imate in the lightbox.
• Add a title attribute to the image: Settings pane > Block > Advanced > Title attribute
• Save and view the post on the front end.
• Hover your mouse on the image.
• Observe the browser doesn't show any tooltip with the title attribute content.

[artemiomorales]

Pinging @jasmussen @SaxonF @jameskoster for feedback.

[artemiomorales]

Here I'll post previous feedback regarding the image and lightbox trigger to inform the current discussion:

To summarise, and https://github.com/WordPress/gutenberg/pull/49621#issuecomment-1509040080, while the interaction might seem simple and straightforward, and the user experience not that of a typical modal dialog, semantically it essentially just that. Which means we should be careful to provide appropriate functionality.

Any trigger that opens the image overlay should (semantically) present as a button, and be labelled appropriately to explain what it does. This means we cannot use the image itself as the trigger, because that should (semantically) present as an image, and have a label reflecting what it actually is ('alt text').

We could hide the trigger button until it receives focus, or the image is hovered, but that brings its own discovery issues and cognitive accessibility questions. Ideally it would be present at all times.

[artemiomorales]

@afercia How about if we put the button into the corner as you've suggested, but only make it available on focus and on hover?

I understand that this approach introduces its own discoverability issues, but it also seems like a reasonable compromise between maintaining a minimal UI, keeping things accessible, and preserving browser behavior.

Thanks for putting together this well-detailed issue and catching these scenarios by the way. We've put in a good amount of work to get the button to render correctly in many, but apparently not all, cases, and it appears the full button overlay is not the best approach.

[afercia]

How about if we put the button into the corner as you've suggested, but only make it available on focus and on hover?

The discoverability problem is in my opinion pretty important. Without any visual hint that the image can be enlarged in a lightbox, how I'm supposed (as a user) to understand the presence of such a feature?

Also, as said earlier, on touch devices there's no hover.

Im not sure I understand what is the advantage with hiding the button. A 'minimal' UI is nice to hav ebut should never come at the expense of user experience. In design, form should follow function, not the other way around.

[jasmussen]

I would echo Artemio's suggestion that a button visible on hover can be a solution. This works well for Substack. The zoom cursor on mouseover instead of the hand cursor provides sufficient context.

[Poliuk]

How about if we put the button into the corner as you've suggested, but only make it available on focus and on hover?

The discoverability problem is in my opinion pretty important. Without any visual hint that the image can be enlarged in a lightbox, how I'm supposed (as a user) to understand the presence of such a feature?

This is, of course, my personal opinion, but I don't think discoverability is such a big deal for a feature like this. Other relevant platforms like Medium or Substack already have an "expand on click" for images, and many people are familiar with this feature.

It's not as if we were launching a never-seen-before feature. For those who are not familiar, I think that the feature is simple enough to get discovered as they browse, and even for the small minority that will learn how to use it later, their UX won't get deeply impacted before they learn.

[artemiomorales]

Thanks all for the input! I’ve thought about this a bit more, and have some additional reflections.

The discoverability problem is in my opinion pretty important. Without any visual hint that the image can be enlarged in a lightbox, how I'm supposed (as a user) to understand the presence of such a feature?

@afercia WordPress allows users to configure links on images, and images are commonly clickable as links throughout the web, including on news websites, site logos, and advertisements. These images as links don’t contain any visual indication to show they’re interactable aside from being able to receive focus and the cursor showing as a pointer when they’re hovered over.

I think a lightbox button then, appearing on hover and on focus, offers the same level of discoverability as in the above cases.

Im not sure I understand what is the advantage with hiding the button. A 'minimal' UI is nice to hav ebut should never come at the expense of user experience. In design, form should follow function, not the other way around.

Thinking of non-technical users who are, in my experience, often overwhelmed by the number of elements on web pages, I think it also makes sense to hide the UI for something that’s not immediately necessary.

There are many different kinds of use cases, but if we take news websites and blogs as an example, the primary function here is to deliver a seamless reading experience. I’d consider that having a small visual obstruction on every image would actually draw attention to itself and away from the content and an image's composition, in particular if we’re considering photography or artwork.

Also, as said earlier, on touch devices there's no hover.

Here we start dealing with tradeoffs. Having a button always visible on mobile overlaid on the image, to the above point, especially one that's large enough to be easily interacted with, could distract from the composition of the image, and I believe having other always-visible UI just on mobile strictly for images would also distract from the experience of consuming the content.

I would echo Artemio's suggestion that a button visible on hover can be a solution. This works well for Substack. The zoom cursor on mouseover instead of the hand cursor provides sufficient context.

@jasmussen Ok got it 👍 I’ve gone ahead and opened a PR.

Happy to hear further thoughts on any of this! 😄 🙏