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 block keyboard focus and tab order #1829

Closed
abrightclearweb opened this issue Jul 10, 2017 · 4 comments · Fixed by #3951
Closed

Image block keyboard focus and tab order #1829

abrightclearweb opened this issue Jul 10, 2017 · 4 comments · Fixed by #3951
Assignees
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).

Comments

@abrightclearweb
Copy link

Tested on: Gutenberg 0.4.

Setup: Mac OS X Sierra, MAMP, Safari 10.1.1.
Gutenberg is the only plugin active.

When you add an image block with the keyboard, it's not clear where the focus goes. VoiceOver says "You are currently on a group".

voiceover add image block

Tabbing through goes from the up/down arrows to cog, delete and then the image positioning and link buttons. Finally, you get to the Insert from Media Library button, after about 12 clicks.

add image gutenberg keyboard focus

Would it not be better to set focus to Insert from Media Library first? The workflow for adding an image in the regular post editor opens up the Insert Media dialog from the Add Media button. I would imagine that most users would want to add an image first before positioning it or moving the block.

@afercia
Copy link
Contributor

afercia commented Jul 10, 2017

Yep, some blocks have a different tab order compared to other ones. Not sure about the technical reasons behind this, if any. However, a consistent tab order and focus behavior across all blocks would be of fundamental importance.

@karmatosed karmatosed added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Jul 10, 2017
@svinkle
Copy link

svinkle commented Jul 13, 2017

I've been digging around the source trying to come up with a solution for this. I wanted to share my thinking to get some feedback and see if I'm on the right track.

Potential solution idea 1

It seem like new block focus() is initiated within block.js:70. By default, the block container receives focus via focus() node method and the element itself with the tabindex="-1" attribute.

What I'd like to suggest is to add a conditional statement to see which block "type" is being inserted. From what I can see, this could be checked using the this.props.block.name property (for example, the image name = "core/image".)

The difficulty I have now with this being able is pass along which element should receive focus. In this case it would be the "Insert from Media Library" <button> element. Could such a reference be passed to block.js as a prop?

Something like:

componentDidMount() {
        if ( this.props.block.name === 'core/image' ) {
                this.props.block.[focusable-element-ref].focus();
	} else if ( this.props.focus ) {
		this.node.focus();
	}
}

Potential solution idea 2

I see that the "Insert from Media Library" <button> element is created in image/index.js:109. I'm wondering if there's a way we could use a focus or setFocus attribute event on this element directly when it's initially created in the view?

Basically, "When this control is created, set focus to it right away."


My React knowledge is greatly lacking at this time (working to change that.) Would there be someone available to @ mention to have a discussion on this? Or if I'm totally off my rocker with these thoughts, please let me know as well. 🙂

@mtias
Copy link
Member

mtias commented Nov 20, 2017

Related: #3560

@jasmussen seems the placeholder could have a focused style and solve both issues.

@jasmussen
Copy link
Contributor

seems the placeholder could have a focused style and solve both issues

I can get behind that, but wouldn't the problem be the same with Image or Gallery blocks?

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).
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants