Image block: further usability and accessibility improvements for the Lightbox

[afercia]

Description

Follow up to #55428

The Image block lightbox has room for further fixes and improvements. See comment #55428 (comment)

• Absence of any visual hint that an image can be enlarged. In a page with many images, where only a few of them open in a Lightbox, users won't have any way to understand the difference unless they hover or focus an image. Not sure this is an ideal design and UX in the first place.
• The image element is clickable and it opens the dialog. This is a not expected interaction and should be reconsidered. Windows screen readers will announce the image as 'clickable'.
• The trigger button should enforce a minimum size of 24 by 24 pixels.
• The Lightbox does not have feature parity with the Navigation, where users can change the appearance of the buttons.
• The modal dialog actually contains two overlid images: they are bot perceivable and will be both announced by assistive technology.
• The icon buttons don't visually expose their accessible name.

Any further usability and accessibility concerns that may arise with more extensive testing should be reported o this ticket.

Step-by-step reproduction instructions

Please see testing instructions and discussions on
#55428
#55414
#55212
#55097

Screenshots, screen recording, code snippet

No response

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]

#55859 introduced a couple accessibility regressions that unfortunately have been released with WordPress 6.4.

• The trigger button size is now 20 by 20 pixels, while it was meant to be 24 by 24 pixels to meet the WCAG 2.2 minimum target size requirement.
• The trigger button background color is now almost fully transparent, which makes the button barely visible with images that have predominant light colors. See in the screenshot below, before and after:

[richtabor]

I don't agree with this sentiment.

The trigger button size is now 20 by 20 pixels, while it was meant to be 24 by 24 pixels to meet the WCAG 2.2 minimum target size requirement.

The entire image is selectable; not just the button.

The trigger button background color is now almost fully transparent, which makes the button barely visible with images that have predominant light colors. See in the screenshot below, before and after:

The transparency is dependent on the background behind the image. It's also blurred; with increased saturation, ensuring the white icon is visible on both the lighted of images, and the darkest. I think this is a subtle enough visible indicator that you can select the image to expand it, without being so dramatic (as originally designed).

[afercia]

I don't agree with this sentiment.

I'd kindly argue that these are subjective opinions. The point here is that the trigger button is now not accessible and violates two success criteria in WCAG 2.2. This is a fact, not a subjective opinion or sentiment.

[richtabor]

The button target is superficial; the entire figure is selectable.

[Bovelett]

WCAG 2.2 guidelines are not subjective sentiments + mobile issue

@richtabor I agree with @afercia on this one where it comes to the WCAG violations. It's not sentiment. The guidelines are there for good reason.

I fully understand where whoever decided for the transparency came from, from an aesthetic point of view. But as much as we designers love aesthetic artful designs, web design remains a creative way to solve problems. It should not create them. Deeming this "a subtle enough visible indicator", is subjective. I may be overlooking it, but I don't see any color / transparency controls for the user who chooses the lightbox functionality. If those indeed aren't there, pushing this on users "by design" is an issue. The contrast on a light background is too low. That's not an opinion. That's a measurable contrast failure. The only reason automated testing doesn't immediately flag it, is because it's a transparent SVG.

The button target is superficial; the entire figure is selectable.

I would kindly ask you to try navigating it yourself with your keyboard only. When you do that, you will see that then there is no indication of the entire image being focusable. (see screenshot). If that was indicated correctly, the focus would be around the entire image, not only on the button.

Food for thought: The impact of this design choice on conversion
By excluding users that way, It's potentially a missed conversion waiting to happen. For example if site users can't immediately see that they can get a larger display by clicking on the small product images in a blog that depends on affiliate marketing. On mobile devices this becomes more apparent. That tiny transparent button appearing by tapping the image once, is almost invisible on a light background.

It's a UI/UX matter that needs to be improved. Either by giving colour and opacity controls to the person adding in the image block, or by making the visibility of the button to be more dramatic by default.

🙏

[afercia]

@Bovelett thank you for your feedback and detailed argumentations. To me, it's time to fix this issue. I'm also changing the label 'Bug' to 'Regression' as the original change is a regression.

This is the before and after reproted earlier:

It's pretty clear this isn't OK.

Also, from an usability and accessibility perspective, there must be a way for users to understand which images have a lightbox and which ones don't. As mentioned earlier:

Absence of any visual hint that an image can be enlarged. In a page with many images, where only a few of them open in a Lightbox, users won't have any way to understand the difference unless they hover or focus an image. Not sure this is an ideal design and UX in the first place.

I'll try a PR soon.

[afercia]

Noting that #54837 aimed to improve the Lightbox buttons styling to make sure they don't conflict with the CSS of a theme that can include styles for button:hover and button:focus but it appears not all cases have been taken into account. For example, Twenty Thirteen alters the padding of buttons on hover and focus, any other theme may alter other properties. Other thenes may use styling for :focus-visible so the reset should be a little broader.

I'd tend to think the lightbox buttons should not be styleable by themes so they should either use a very high specificity or even ! important.

Twenty Thirteen default

Twenty Thirteen while clicking the button to open the lightbox i.e. :hover:active.

[afercia]

One of the issues original reported on #55428 (comment) is about the absence of any visual hint that an image can be enlarged. In a page with many images, where only a few of them open in a Lightbox, users wan't have any way to understand the difference unless they hover or focus an image.

This applies to the editor canvas as well, where there's no visual hint at all not even when hovering or focusing the image. The only wai to understand an image has a lightbox is:

• select the image
• observe the 'link' button in the block toolbar is pressed, but this is what happens for any link so it isn't a direct indication of the lightbox being enabled
• click the 'link' button and observe the UI shows the 'Expands on click' UI

That is at least two clicks to understand whether an image has the lightbox enabled. Not sure that's an ideal user experience and I think there should be a clear visual hint in the editor as well.

As an example, the screenshots below illustrate a series of images where some of them do have a lightbox and some don't, but there's no way to understand the difference.