Skip to content

Conversation

gcamacho079
Copy link
Contributor

Description

Setting the activate listener on the <body> element caused tabindex="0" to be set on the body element. After opening the Image Editor modal, clicking anywhere inside would set focus on the body — not inside the current layer — since the body itself was focusable.

This PR checks to make sure it doesn't set tabindex="0" on the body element to prevent focus from being dropped into the wrong layer.

Related issues

@gcamacho079 gcamacho079 requested a review from brandonkelly June 16, 2025 16:37
@gcamacho079 gcamacho079 added bug accessibility 👤 features related to accessibility labels Jun 16, 2025
Copy link

linear bot commented Jun 16, 2025

@brandonkelly
Copy link
Member

@gcamacho079 What are the steps to reproduce the bug, which demonstrate this PR’s fix? The behavior seems the same to me on 5.x and this branch – either way, if I click somewhere within the image editor, I’m unable to tab back to any of the Image Editor inputs.

@gcamacho079
Copy link
Contributor Author

@brandonkelly of course! To reproduce the issue:

  1. Go to an asset page and open the Image Editor
  2. Click anywhere on the Image Editor modal background (i.e., not on an input)
  3. Hit the Tab key

Outcome (5.x): Keyboard focus is reset to the body tag, so the next item to receive focus is the "Skip to main section" link
Expected behavior: Focus should move to a button or field inside the Image Editor modal. The item that receives focus will vary based on where the user clicks.

I'm getting the expected behavior on this branch, but it sounds like you're still seeing focus move to the skip link?

@brandonkelly
Copy link
Member

Yeah, seeing the same behavior on both 5.x and this branch. On Chrome, both branches behave as expected; on Firefox, both branches take 10 Tab presses before focus makes it to the “Rotate” button. Strangely, any follow-up clicks on the background only take four Tab presses to get to “Rotate”.

@gcamacho079
Copy link
Contributor Author

@brandonkelly Interesting! I wonder if there's something in another layer that's stealing the focus. 🤔 I haven't been able to replicate. Could you run the following code in the console so we can see what's getting that focus after you click?

document.body.addEventListener('focusin', (event) => {
  console.log(document.activeElement);
});

In the meantime, I may work on adding some fallback code in the Modal JS to make sure keyboard focus is in the correct layer after the first mousedown or tab.

…is-first-in-the-focus-order

# Conflicts:
#	src/web/assets/garnish/dist/garnish.js
#	src/web/assets/garnish/dist/garnish.js.map
[ci skip]
@brandonkelly brandonkelly merged commit 6e5953d into 5.x Aug 1, 2025
2 checks passed
@brandonkelly brandonkelly deleted the feature/pt-2770-identify-why-skip-to-content-is-first-in-the-focus-order branch August 1, 2025 23:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility 👤 features related to accessibility bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants