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

Focus loss when setting featured image #14414

Closed
afercia opened this issue Mar 13, 2019 · 0 comments · Fixed by #14415
Closed

Focus loss when setting featured image #14414

afercia opened this issue Mar 13, 2019 · 0 comments · Fixed by #14415
Labels
[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 Mar 13, 2019

When setting a Featured Image, the Media Modal opens. The Media Modal takes care of moving focus back to the "opener" element when it closes. This is the button that opened the modal.

However, the "Set featured image" button gets removed from the DOM

{ ! featuredImageId &&
<div>
<MediaUploadCheck fallback={ instructions }>
<MediaUpload
title={ postLabel.featured_image || DEFAULT_FEATURE_IMAGE_LABEL }
onSelect={ onUpdateImage }
allowedTypes={ ALLOWED_MEDIA_TYPES }
modalClass="editor-post-featured-image__media-modal"
render={ ( { open } ) => (
<Button className="editor-post-featured-image__toggle" onClick={ open }>
{ postLabel.set_featured_image || DEFAULT_SET_FEATURE_IMAGE_LABEL }
</Button>
) }
/>
</MediaUploadCheck>
</div>
}

There's no reference any longer to the opener element and the Media Modal can't move focus back to it.

As accessibility team, we've warned many times special care should be taken when removing, hiding, or disabling "focus-candidate" elements from the DOM. In the case of modals, focus should always be moved back to a proper place in the "invoking context".

Focus losses need to be avoided because they're a terrible experience for keyboard and screen reader users. Even though modern browsers have implemented a sort of sequential focus navigation starting point that just tries to keep focus "in place" and, technically, there's no focused element. Also, it's not guaranteed to work, especially when using assistive technologies.

We've seen other cases in Gutenberg where a mechanism to determine a fallback where focus should be moved back would be useful. Not sure how to implement it.

In this specific case, worth noting the image preview is a button: specifically, a MediaUploadCheck component that renders also a button. I guess using the same MediaUploadCheck for both the "Set featured image" button and the image preview button could solve the issue.

@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). labels Mar 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[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.

1 participant