Wrapped anchor tag around the image and caption for gallery block

[ashwin-pc]

Description

Fixes #14304. In the saved version of the post the anchor tag is now wrapped around the whole figure and not just the image. This is done only in the saved post to maintain interaction with the caption editor in the edit mode.

How has this been tested?

• Passed all unit test cases using npm test
• Manually tested by clicking on the gallery image with and without the Link To property being set. When Link To is not None the entire image can be clicked. When it is set to None, clicking the image does nothing.

Screenshots

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[gziolo]

I just wanted to repeat the question from @mapk:

I think that in HTML5 you can wrap an anchor around pretty much anything apart from other interactive elements.

Let's move in this direction. Are there any a11y issues that we should anticipate regarding this change?

If we get the green light for this approach, we will have to add an entry to deprecation field to ensure that the existing blocks don't break as the effect of different HTML markup outputted by save method. More details here: https://wordpress.org/gutenberg/handbook/designers-developers/developers/block-api/block-deprecation/. Let's wait with that until we get confirmation from the Accessibility team.

Question posted in #accessibility channel on WordPress Slack (link requires registration): https://wordpress.slack.com/archives/C02RP4X03/p1554878707014200

[gziolo]

@ashwin-pc, could you add an example of the generated markup in the issue? It would make it easier to review this PR.

[afercia]

Stepping in after @gziolo invitation to comment on the proposed new markup. See also general considerations on the related issue #14304 (comment)

While the link wrapping the figure is valid markup, from an accessibility perspective things are pretty different because the semantics changes. With the new markup, the gallery is actually a list of links instead of a list of figure elements.

Considering semantics in an abstract way, we could debate if the caption being part of the link is valid markup. To me, it is not because the linked "object" should be the image. However, I'm more interested in the practical consequences of the new markup in the way the content is perceived and announced by assistive technologies. The experience of users who use assistive technologies is way more important than academic discussions about semantics.

Testing with a couple browser / screen reader combinations, turns out there are relevant differences in the two markups.

In the screenshot below: Firefox and NVDA before and after:

With the current markup, a linked image is announced in a pretty clean way:

• the figure is announced as "grouping"
• the figure accessible name is determined by the figcaption content "Coastline in Huatulco, Oaxaca, Mexico"
• the image accessible name is determined by the image alt attribute "Huatulco Coastline"
• it says there's an image ("graphics") and a link
• note: in the case of linked image, the alt text should describe the link purpose

With the new markup:

• the figcaption content is announced as part of the link content (because actually it is part of it): this doesn't look correct to me and, at the very least, adds a lot of redundant information and noise for screen reader users

Safari and VoiceOver

Before:

Every piece of relevant information from the content is announced:
it says there's a link and an image, it reads out the alt text and the figcaption content, it says it's a figure

After:

• it only announces there's a link and reads out the figcaption as content of the link
• the image and its alt text are ignored so users wouldn't have any clue of the link's purpose

Note: VoiceOver offers the ability to "Interact with an item" via the dedicated shortcut VO-Shift-Down Arrow. Theoretically, this would offer users the ability to "enter" the link and explore its children. In this case the image would be announced. However, users wouldn't expect they have to do this additional step.

Recap

Inconsistencies between browsers / screen readers behaviors are pretty normal when they encounter some unusual, unexpected, markup. Regardless, it appears the new markup produces a pejorative experience for assistive technologies users and I'm afraid I can't recommend this change.

I'd suggest to explore an alternative approach. I'd tend to think the root cause of this issue is the CSS positioning, therefore this would probably better solved with CSS. Some thoughts:

• does the caption need to stay visible when the image is hovered? -> consider to hide it, or truncate it, or reduce its height on hover (or any other "smart" behavior)
• does the caption text need to be selectable with the mouse to copy it? -> consider to use pointer-events: none
• should the caption behavior be handled by the theme instead of by Gutenberg? See Anchor Tags In Gallery Images Are Covered by the Caption, Rendering Them Unclickable #14304 (comment)

I'd also like to hear thoughts from other accessibility team members, will take care of soliciting feedback.

[anevins12]

We shouldn't be changing the semantics (for everyone) to achieve a bigger hit area (for some users). Instead we should be enhancing the experience using JS. In this case we can take the destination of the link and bind a click event on its relating image. This is a plugin that does that for demonstrative purposes. We do not have to use that plugin, but I am showing the implementation that I recommend we achieve: http://lawlesscreation.github.io/jquery.clickable/

[ashwin-pc]

@afercia I'd like to propose another solution which i believe will not change the semantics for a screen reader, you can correct me if I'm wrong on this.

Instead of wrapping the figure in the anchor tag, we can wrap another anchor tag around the caption too but set aria-hidden="true".

Before (Original):

<figure>
    <a href="#">
        <img src="" alt="">
    </a>
    <figcaption>Caption</figcaption>
</figure>

After:

<figure>
    <a href="#">
        <img src="" alt="">
    </a>
    <a href="" aria-hidden="true">
        <figcaption>Caption</figcaption>
    </a>
</figure>

This change will address both the users ability to select the caption and have a bigger hit area while not affecting accessibility.

[afercia]

@ashwin-pc unfortunately aria-hidden="true" doesn't work this way, especially when used on interactive elements. The second link would still be focusable and keyboard users can navigate to it. Screen reader users will hear an "empty" tab stop. Even using tabindex="-1" wouldn't help because screen reader users can navigate to the link by other means.

[afercia]

One more reason why I'd tend to think captions should have a smarter behavior is that captions can be very long. It's an edge case but when captions are very long, not only the image is not clickable but also can't be seen very well... 🙂 Example:

[afercia]

Discussed during today's accessibility bug-scrub. Removing the "Needs Accessibility Feedback" label, as initial feedback has been given. Keeping the "Accessibility" label will still allow anyone interested in a11y to participate.

[mapk]

I think @afercia provided some reasonable alternatives that meet a11y requirements.

• does the caption need to stay visible when the image is hovered? -> consider to hide it, or truncate it, or reduce its height on hover (or any other "smart" behavior)

Can we try this? Hide the caption on hover if the caption covers the image.

• does the caption text need to be selectable with the mouse to copy it? -> consider to use pointer-events: none

I suggest we keep the caption as selectable.

• should the caption behavior be handled by the theme instead of by Gutenberg? See Anchor Tags In Gallery Images Are Covered by the Caption, Rendering Them Unclickable #14304 (comment)

I'd like to see us offer different styling alternatives for captions as mentioned in the issue here. This could totally be another PR though.

[gziolo]

• does the caption need to stay visible when the image is hovered? -> consider to hide it, or truncate it, or reduce its height on hover (or any other "smart" behavior)

Can we try this? Hide the caption on hover if the caption covers the image.

@ashwin-pc, can you just hide the caption on hover of the image for now? Let us know if you would like to continue working on this fix. I can take it over if you are busy with something else now that a few weeks have passed.

[gziolo]

See my previous comment.

[ashwin-pc]

@gziolo Sure, you could take this over. I'm slightly tied up at the moment and not entirely sure what's expected of the fix.

[afercia]

Worth considering one of the previous questions

does the caption text need to be selectable with the mouse to copy it?

Hiding the caption when hovering it would make impossible to select and copy the caption text.

[mapk]

does the caption text need to be selectable with the mouse to copy it?

Hiding the caption when hovering it would make impossible to select and copy the caption text.

This is correct. I'm willing to take this tradeoff because I believe clicking an image to view it at a larger scale is the prefered action here. This PR can work toward this, and in the future we can create a PR that adds another style variation where the captions are below the images.

[gziolo]

@gziolo Sure, you could take this over. I'm slightly tied up at the moment and not entirely sure what's expected of the fix.

Thanks for letting us know. I will close this PR. Thank you for your contribution, it helped to clarify what needs to be done 👍