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

Audio Block: manage focus after media library modal close #27521

Open
alexstine opened this issue Dec 4, 2020 · 7 comments
Open

Audio Block: manage focus after media library modal close #27521

alexstine opened this issue Dec 4, 2020 · 7 comments
Assignees
Labels
[Block] Audio Affects the Audio Block [Block] File Affects the File Block [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Dev Ready for, and needs developer efforts [Type] Bug An existing feature does not function as intended

Comments

@alexstine
Copy link
Contributor

Describe the bug

This is an accessibility issue that happens when using the Audio Block in Gutenberg. Focus is not managed properly after the media library modal is closed or a media file is selected.

To reproduce

  1. Insert an Audio Block.
  2. Select Media Library.
  3. Select a file from your media library or upload a new one.
  4. Select the Select button.
  5. Notice how screen reader focus is now on Undo, Redo, or Schedule buttons instead of in the block that you were working on.

Expected behavior

I expected to be dropped back in my currently selected block, not somewhere else in the editor.

Editor version (please complete the following information):

  • WordPress version: 5.6 RC3

Desktop (please complete the following information):

  • OS: Windows 7
  • Browser Firefox
  • Version 83.0
@joedolson
Copy link
Contributor

I was not able to reproduce this, but I did find the new focus to be less than totally helpful. It seems to me that the best target focus on selecting media would be the 'Replace' button. This should allow for quick error correction. Along with that, I think that the current media URL data point should also include the media title, so that users can more easily tell which file is included.

@skorasaurus skorasaurus added the [Block] Audio Affects the Audio Block label Dec 5, 2020
@Lewiscowles1986
Copy link
Contributor

How do the labels work?

Surely as all media uses shared components, albeit supplying different arguments; this would affect Image, Video, etc as well?

https://github.com/WordPress/gutenberg/blob/master/packages/block-library/src/audio/edit.js#L137-L145 is the usage for Audio. But this defers to another shared component <MediaReplaceFlow>

Getting right into the guts as far as https://github.com/WordPress/gutenberg/blob/master/packages/media-utils/src/components/media-upload/index.js the level of indirection was not ideal for me, but it seems like multiple components should experience similar behavior.

@youknowriad
Copy link
Contributor

I tried working a bit on this issue and for me the focus moves back to the block and this makes sense to me since the placeholder is not longer visible.

@alexstine
Copy link
Contributor Author

Focus is never moved back to the block for me. Let me try to record a video so you can see what's going on. Maybe the issue is very specific to me somehow.

@t-hamano
Copy link
Contributor

I was able to reproduce this problem with the post editor, not the site editor. I also think that this problem is not limited to audio blocks.
Some examples are described below.

After selecting media in the media library and pressing the Select button:

  • Audio Block: Loses focus. However, if the Tab key is pressed, the block gets focus.
  • File Block: Loses focus. However, if the Tab key is pressed, the block gets focus.
  • Image Block: The caption area gets focus, but the block does not. When the tab key is pressed, focus appears to be lost from the editor.

@alexstine
Copy link
Contributor Author

Wow, how sad. This issue is assigned to me and I forgot all about it. I thought for sure this would be fixed after some adjustments in useBlockProps, but I guess not.

@annezazu By any chance, do you know of anyone with bandwidth right now to look in to this one? That person just is not me.

@alexstine alexstine 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). Needs Dev Ready for, and needs developer efforts [a11y] Keyboard & Focus [Block] File Affects the File Block labels Sep 28, 2022
@annezazu
Copy link
Contributor

@talldan or @carolinan might either of you have time in the coming weeks as 6.1 settles?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Audio Affects the Audio Block [Block] File Affects the File Block [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Dev Ready for, and needs developer efforts [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

8 participants