Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image: fix focus management and accessibility of the Lightbox #55414

Closed
afercia opened this issue Oct 17, 2023 · 3 comments · Fixed by #55428
Closed

Image: fix focus management and accessibility of the Lightbox #55414

afercia opened this issue Oct 17, 2023 · 3 comments · Fixed by #55428
Assignees
Labels
[Block] Image Affects the Image Block [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended

Comments

@afercia
Copy link
Contributor

afercia commented Oct 17, 2023

Description

Follow-up to #55212

#55212 improved the Lightbox implementation by changing the button that overlid the entire image to a smaller button placed at the top right of the image. That's a welcome change that solves a couple important issues. It also introduced a different implementation of focus handling of the modal dialog that needs to be fiexed.

Please refer the inline review on #55212
Quoting from the last comment there:

  • The implementation based on event.pointerType is buggy, as Chrome and Opera return an empty string (as expected) when using the keyboard while Firefox and Safari return undefined.
  • Regardless, differentiating the behavior depending on pointing device vs. 'other' is not OK for accessibility. The modal dialog focus management should always have the same behaevior regardless of mouse, touch, keyboard, other.
  • The assumption that users are always either using a pointing device or other is incorrect. For example, I may want to open the modal dialog with a click and close it by pewssing the Escape key.

Depending on the flow used to open the dialog and on the browser in use, this is what I observed when testing:

  • When opening the dialog, focus is not transferred to the dialog. As such:
    • Focus stays on the page behind the dialog. Tabbing will navigate the page content behing the modal dialog.
    • The dialgo is not announced by screen readers because focus is elsewhere.
    • The dialog doesn't close on Escape.
    • When closing the dialog, focus should always return to the trigger button, instead this is not the case.
    • As such, there is a full focus loss: tabbing again will restart the tab order from the document root.
  • The trigger button doesn't visually expose its accessible name. This is a broadeer issue with all icon buttons ued on the front end and should be addressed holistically.
  • The trigger button is only 24 by 24 pixels. While this is compliant with the current WCAG 2.2, I would like to see the button target size a little larger.
  • When opening the modal dialog, Initial focus should go to the element with role=dialog instead of the Close button.
  • The clickable image is problematic. I'm not sure why we want to make a HTML element have a non-native behavior. I'm not sure that would make it more usable in the first place, as it is a non expected beheavi, especially considering the following point. It is even more problematic on mobile.
  • Still, there is no visual hint that the image can be enlarged. It looks like a normal image and only when hovered or focusd shows a visual hint. As a user, looking at a page with a Lightbox image, I wouldn't have any clue that the image can be enlarged. See screnshot below: how users are supposed to understand the image can be enlarged?

Screenshot 2023-10-17 at 13 12 47

Step-by-step reproduction instructions

Testing on macOS:

  • Add an image block and set the image to open in the Lightbox.
  • Publish and view the front end.
  • Makes sure full keyboard navigation is enabled in your macOS settings under Keyboard. See screenshot:

Screenshot 2023-10-17 at 15 42 46

  • With macOS Chrome:
    • Tab to the button that opens the image modal dialog.
    • Press Enter or Spacebar.
    • Observe that focus is moved to the modal dialog Close button, as expected.
  • With macOS Firefox:
    • Repeat the steps above.
    • Observe focus is not moved to the modal dialog.

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 afercia added [Type] Bug An existing feature does not function as intended [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Block] Image Affects the Image Block Backport to WP 6.7 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta labels Oct 17, 2023
@artemiomorales artemiomorales self-assigned this Oct 17, 2023
@artemiomorales
Copy link
Contributor

@afercia Thanks for opening this issue! I've opened a PR to address the focus management items. Here follow some notes:

The trigger button doesn't visually expose its accessible name. This is a broadeer issue with all icon buttons ued on the front end and should be addressed holistically.

As you've suggested before, the solution here will probably require implementing tooltips or something similar and will require a larger effort to get right.

The trigger button is only 24 by 24 pixels. While this is compliant with the current WCAG 2.2, I would like to see the button target size a little larger.

The answer here is likely to allow users to configure the size of the button. For now, I'd prefer to start with a small button. Perhaps @richtabor would like to weigh in?

When opening the modal dialog, Initial focus should go to the element with role=dialog instead of the Close button.

I'm on board with this, but after implementing it, I've run into a problem with Safari when using VoiceOver wherein focus is announced to be on the Close button but using the Enter key is unresponsive. Do you have any suggestions on an alternative approach?

  • The clickable image is problematic. I'm not sure why we want to make a HTML element have a non-native behavior. I'm not sure that would make it more usable in the first place, as it is a non expected beheavi, especially considering the following point. It is even more problematic on mobile.

  • Still, there is no visual hint that the image can be enlarged. It looks like a normal image and only when hovered or focusd shows a visual hint. As a user, looking at a page with a Lightbox image, I wouldn't have any clue that the image can be enlarged. See screnshot below: how users are supposed to understand the image can be enlarged?

This discussion was brought up in a previous issue as well — I'll refer to this comment, which captures my thoughts. To summarize, I think having a clickable image and a visual hint on hover is a good balance of offering additional functionality while also preserving the core UX of offering a good reading experience, though am happy to hear other ideas.

@artemiomorales artemiomorales linked a pull request Oct 17, 2023 that will close this issue
@afercia
Copy link
Contributor Author

afercia commented Oct 19, 2023

Thanks @artemiomorales. The Yoast team will have a look at the PR today during a mob-coding session.

As you've suggested before, the solution here will probably require implementing tooltips or something similar and will require a larger effort to get right.

I agree this can't be addressed now as it's a broader issue. However, I would have liked to see a setting to change the appearance of the buttons from icon to text as done for the Navigation, also for consistency. I'm not sure I understand why users can control the buttons appearance of the Navigation and they can't do for the Lightbox:

Screenshot 2023-10-19 at 08 37 03

I already planned to create a separate issue for this.

The answer here is likely to allow users to configure the size of the button. For now, I'd prefer to start with a small button. Perhaps @richtabor would like to weigh in?

We should make sure that any markup output by WordPress is accessible and compliant. Allowing users to configure the size to enlarge it is certainly a good thing. But, we should force a minimum size of 24 by 24 pixels.

@afercia
Copy link
Contributor Author

afercia commented Oct 19, 2023

I think having a clickable image and a visual hint on hover is a good balance of offering additional functionality while also preserving the core UX of offering a good reading experience,

Regarding the visual hint, I kindly disagree. This:

lighbox image

doesn't let users understand the image can be enlarged. Visually, there's no way to understand it, unless that by accident useers hover or focus the image. I'm not sure this is any good.

I'd also liek to remind everyone that on mobile there is no hover.

@SiobhyB SiobhyB removed the Backport to WP 6.7 Beta/RC Pull request that needs to be backported to the WordPress major release that's currently in beta label Oct 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Image Affects the Image Block [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants