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

Block gallery: delete image with delete or backspace keys #14822

Merged
merged 3 commits into from Apr 12, 2019

Conversation

@nosolosw
Copy link
Member

commented Apr 4, 2019

Fixes #14816

Peek 2019-04-04 16-51

@youknowriad
Copy link
Contributor

left a comment

the code changes are good, but I'd like an accessibility check here.

@afercia

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

I've quickly tested with various browser / screen reader combinations and the removal works. A bit surprisingly because I wasn't expecting onKeyDown to work on non-natively interactive elements when screen readers are not in "focus mode". We've already faced this issue in other components, @aduth might remember something about it.

Regardless, it works.

A pre-existing issue (triggered also when removing an image via the dedicated button) is that focus is not managed. When the selected image (currently focused element) gets removed, there's no focused element any longer so a focus loss happens.

Focus should be moved to the most logical place. Not sure what the best place is 🙂 Ideally:

  • to the previous image, if any
  • otherwise to the following image, if any
  • otherwise if it's the last image: to the block focusable container

I do realize this would be complicated so I'd be OK with always moving focus to the block focusable container: at least it would avoid a complete focus loss.

I also do realize it's not strictly related to this PR so it might be addressed separately but since we're here... 🙂

@aduth

This comment has been minimized.

Copy link
Member

commented Apr 11, 2019

A bit surprisingly because I wasn't expecting onKeyDown to work on non-natively interactive elements when screen readers are not in "focus mode". We've already faced this issue in other components, @aduth might remember something about it.

If I'm recalling correctly, there was a specific impact of both the specific key pressed and the effective role of the element in how keyboard events were treated between focus and browse modes (#5595).

@afercia

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

If I'm recalling correctly, there was a specific impact of both the specific key pressed and the effective role of the element in how keyboard events were treated between focus and browse modes

Yep, evidently it works on images (implicit role=img).

@nosolosw

This comment has been minimized.

Copy link
Member Author

commented Apr 12, 2019

Created an issue for the focus loss at #14946

@nosolosw

This comment has been minimized.

Copy link
Member Author

commented Apr 12, 2019

OK, I'm going to go ahead here and land this so it's in the list of bugfixes to port to WordPress 5.2.

Shameless self-promotion in case anyone has time to review related gallery bugfixes that deal with keyboard navigation and focus management: #14930 and #14821 I'm going to be out next week, but I'll try to save a couple of hours tomorrow or perhaps Sunday in case reviews come today when I' already AFK. It'd be nice to get those bugfixes in as well!

@nosolosw nosolosw merged commit 880a4bb into master Apr 12, 2019

1 check passed

Travis CI - Pull Request Build Passed
Details

@nosolosw nosolosw deleted the add/gallery-delete-image branch Apr 12, 2019

mchowning added a commit to mchowning/gutenberg that referenced this pull request Apr 15, 2019

This was referenced Apr 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.