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.

[felixarntz]

@afercia I am currently exploring enhancements for the lightbox implementation and just read through the discussion here. I have a few questions:

• Would it help with screen reader support to wrap the entire img in a button element, instead of just that small on-hover indicator? I am thinking that semantically this would be more accurate because clicking the image opens the lightbox, not only the on-hover indicator.
• If the img was wrapped in a button, the on-hover indicator of course couldn't be a button anymore - but that wouldn't be an issue since it's only overlaying the image anyway and would appear within the button to open the lightbox as well. Maybe that indicator could be changed to not only appear on hover, but permanently? That way images that allow opening a lightbox would permanently be differentiated from images without a lightbox, which I would think is better than only show that differentiation on hover.

[afercia]

Would it help with screen reader support to wrap the entire img in a button element

I'm not sure that would be ideal. Rather, thinking especially at the Gallery, I'd envision a routing mechanism integrated with the browser history API to allow navigation through images in a gallery. With that in place, navigating to each enlarged image would be sort of navigation to another resource so that a link wrapping the image would make more sense. Alas, so far, the Gallery doesn't allow navigation and it's only a basic implementation.

Maybe that indicator could be changed to not only appear on hover, but permanently? That way images that allow opening a lightbox would permanently be differentiated from images without a lightbox, which I would think is better than only show that differentiation on hover.

I'd definitely agree the trigger button should always be visible otherwise there's no way to distinguish which image has a lightbox and which not. Right now, users have to discover it by trying to hover or focus all the images.

As an higher level consideration, I think the fundamental problem with the Interactivity API is that, so far, the HTML output is opinionated. Traditionally, WordPress has always provided ways to filter and change any HTML output. That was in the era where the front end was a theme authors responsibility. Now that the block editor shifts that responsibility to content creators and puts all the power in their hands, I think the editor should at the very least provide settings to change the output.

For example, the Navigation block does provide settings to collapse the menu into an expandable panel and settings to change the button that opens the menu. In fact, the button can be set to show only an icon or text. Screenshot:

Similarly, the Image (and Gallery) block should provide settings to change the output. At the very least, there should be a setting to change the trigger button from an icon-only button to a button with visible text. I'd like to remind that icon-only buttons are not accessible especially when they don't visually expose their accessible name (and there's no Tooltip to use for the front end). A setting to show text would make the front end output more accessible, leaving the responsibility of the decision to content creators. Screenshot to better illustrate:

I did start some work to implement the icon/text setting but postponed it so far because of the complexity due to dealing with theme settings and global settings. Hopefully I'll be able to resume that work soon.

[felixarntz]

@afercia

Would it help with screen reader support to wrap the entire img in a button element

I'm not sure that would be ideal. Rather, thinking especially at the Gallery, I'd envision a routing mechanism integrated with the browser history API to allow navigation through images in a gallery. With that in place, navigating to each enlarged image would be sort of navigation to another resource so that a link wrapping the image would make more sense. Alas, so far, the Gallery doesn't allow navigation and it's only a basic implementation.

Makes sense regarding gallery. How about a single image block though? There's no navigating through multiple images there, it's only to show the one image in a lightbox.

Maybe that indicator could be changed to not only appear on hover, but permanently? That way images that allow opening a lightbox would permanently be differentiated from images without a lightbox, which I would think is better than only show that differentiation on hover.

I'd definitely agree the trigger button should always be visible otherwise there's no way to distinguish which image has a lightbox and which not. Right now, users have to discover it by trying to hover or focus all the images.

Makes sense to me, thanks! 👍

Similarly, the Image (and Gallery) block should provide settings to change the output. At the very least, there should be a setting to change the trigger button from an icon-only button to a button with visible text.

I think this would make sense to have a UI control for, and it should be totally feasible given there's pre existing art with the navigation overlay toggle as you mentioned.

[afercia]

Makes sense regarding gallery. How about a single image block though? There's no navigating through multiple images there, it's only to show the one image in a lightbox.

The semantic and experience for images should be consistent for single images and images in a gallery. I'm not sure wrapping a single image within a button would add value for users in the first place. An image is content and sgould not live inside an interactive control.
Thinking at the routing mechanism envisioned for galleries, also a single image may use that pattern if we make the decision that the lightbox is sort of link to another resource.

[felixarntz]

I'm not sure wrapping a single image within a button would add value for users in the first place.

Doesn't doing so clarify that you can click on the image? Currently, without being a button, there are no semantics indicating that the image opens a lightbox.

An image is content and sgould not live inside an interactive control.

If an image should not be in a button, how should this then work for galleries, where you are saying that a lightbox would make more sense? How would users open the gallery view?

Thinking at the routing mechanism envisioned for galleries, also a single image may use that pattern if we make the decision that the lightbox is sort of link to another resource.

Are you suggesting that we use e.g. a tags pointing to the media file? And clicking that could open the lightbox?

[afercia]

there are no semantics indicating that the image opens a lightbox.

There is a separate button for that reason. The image itself opens the lightbox only with pointing devices / touch.

• Buttons are for actions.
• Links are for navigation.

If there was a routing mechanism, for both single image and for galleries, I would have no big objections to consider the lightbox as sort of navigation to another resource, which would make a link <a> tag semantically appropriate. Hope this answers also your second point.

Would love to hear thoughts also from others passionate about semantics and expected interaction Cc @joedolson

[joedolson]

I think it's reasonable to offer options where a link is appropriate, but it does depend on having a routing mechanism that makes the URL for that link navigable, and I can definitely see use cases - like sharing a link to a specific image in a gallery - where it would be desirable to link directly to the lightbox open for that image.

But if there's no way to navigate to a particular view by URL, then you shouldn't trigger that view using a link.

[felixarntz]

@joedolson Would it be reasonable to wrap the image in a link (a) to its full-size media file, add relevant listeners and markup to open a lightbox with that image, and use the browser history API to alter the URL to indicate that full-size media file is being viewed? Then when the lightbox is closed, it could alter the browser history back to the previous URL.

In other words, the lightbox would be an alternative way to view that full-size image file.

[joedolson]

The raw image file is a different user experience than the image in a lightbox - as a raw image, it won't have any alternative text, captions, or any other kind of accessibility-supported information. So even though that would technically fulfill the idea of providing a link target, it's providing different information depending on how you reach the URL, and I don't really think that's a good experience.

[joedolson]

If the link action appended a fragment identifier to the URL, and used that as a trigger to open the light box at entry, then I think that would be more equal. The fragment identifier should probably not actually target an ID attribute, so that browser-native fragment navigation would still work, but could be read from the URL to determine which lightbox to trigger.

[felixarntz]

Thanks, that makes sense. So potentially we could use a link like #wp-core-image-lightbox-{attachment_id} and based on that identify which image on the page to open the lightbox for. If someone accesses that URL directly, that lightbox would be open by default.

Related question: When closing the lightbox, should that URL fragment be removed via browser history API, or is no change needed (i.e. it would remain)? I'm asking since out of the box, I believe clicking the link to open the lightbox would add it, but the close button wouldn't remove it.

[joedolson]

It should be removed, I think.