You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Improve Accessibility for Adding Blocks in the Block Editor for Screen Reader Users #71466
This feature addresses accessibility challenges faced by visually impaired users and Screen Reader users. The current workflow requires navigation and interaction with the screen, which can be difficult.
By automatically focusing the cursor in the block search bar and streamlining block selection, we can reduce friction and make it easier to add blocks.
It solves the problem of:
Users struggling to locate the search bar and interact with block options.
Easier accessibility to the block editor for users who have visual impairments.
What is your proposed solution?
This is what the user suggested:
When a user activates the "Add Block" button, set the focus on the search bar for the block.
Allow the user to type the name of the block (e.g., "image") and press Enter to insert it directly into the editor.
If multiple block options are available, automatically focus on the first block option in the results list after the user presses Enter.
This was requested under Automattic/wp-calypso#98239 so I'm moving it to core as I'm unable to find an equivalent request.
The editor has a couple of inserters, but based on the button label, it seems we're referring to Quick Inserter and best to my knowledge, it's accessible.
Clicking the "Add Block" button focuses the search control and type, allowing the user to use the Tab to navigate to the block options.
Using "Enter" sounds like an interesting suggestion, similar to how the block autocompleter works, but they're different UI patterns, with their defined a11y best practices.
@joedolson, @jeryj, you've worked on these UI components. What do you think?
1: Set the focus on the search bar after pressing 'Add Block'
Assuming we're talking about the quick inserter, then this is already what happens - so I'm not sure what we would change here. I do think that the quick inserter is difficult to find using the keyboard - it appears visually at the end of the block, but is before the block content in tab order, which makes it non-obvious to locate, especially if you're not sighted and have no visual cue that it exists.
That's not what this is requesting, however.
2: Allow the user to type the name of the block and press Enter to insert
This could be a useful shortcut. If you're already positioned on the home keys, you can more easily type "image" and press 'Enter' than you can type "imag", then locate the tab key, press it twice, then press enter. I think this shortcut would potentially be useful for any user - just hit 'enter' from the search bar to insert the first item in the list. As long as there was a post-search announcement to inform the user which block would be inserted, I think this would be useful.
3: Focus the first item in the list if multiple options.
I'm not convinced this would be helpful. Mostly because it makes the behavior of 'Enter' in the search field harder to predict, but also because there are some blocks that you can't narrow down to just one result. For example, you can't narrow a search for 'Columns' to just one item, because 'Table' always comes up for that query. (This may be an argument for not mis-categorizing blocks like that. Tables are not columns; they are grids.)
Closing this out as there doesn't appear to be anything clearly actionable here. Happy to reopen if others believe otherwise. With that said, I'd prefer a separate and clearer issue with a proposal be opened instead to make it easier for those wanting to contribute.
Activity
Mamaduka commentedon Sep 3, 2025
The editor has a couple of inserters, but based on the button label, it seems we're referring to Quick Inserter and best to my knowledge, it's accessible.
Clicking the "Add Block" button focuses the search control and type, allowing the user to use the Tab to navigate to the block options.
Using "Enter" sounds like an interesting suggestion, similar to how the block autocompleter works, but they're different UI patterns, with their defined a11y best practices.
@joedolson, @jeryj, you've worked on these UI components. What do you think?
Screenshot
joedolson commentedon Sep 4, 2025
1: Set the focus on the search bar after pressing 'Add Block'
Assuming we're talking about the quick inserter, then this is already what happens - so I'm not sure what we would change here. I do think that the quick inserter is difficult to find using the keyboard - it appears visually at the end of the block, but is before the block content in tab order, which makes it non-obvious to locate, especially if you're not sighted and have no visual cue that it exists.
That's not what this is requesting, however.
2: Allow the user to type the name of the block and press Enter to insert
This could be a useful shortcut. If you're already positioned on the home keys, you can more easily type "image" and press 'Enter' than you can type "imag", then locate the tab key, press it twice, then press enter. I think this shortcut would potentially be useful for any user - just hit 'enter' from the search bar to insert the first item in the list. As long as there was a post-search announcement to inform the user which block would be inserted, I think this would be useful.
3: Focus the first item in the list if multiple options.
I'm not convinced this would be helpful. Mostly because it makes the behavior of 'Enter' in the search field harder to predict, but also because there are some blocks that you can't narrow down to just one result. For example, you can't narrow a search for 'Columns' to just one item, because 'Table' always comes up for that query. (This may be an argument for not mis-categorizing blocks like that. Tables are not columns; they are grids.)
annezazu commentedon Oct 7, 2026
Closing this out as there doesn't appear to be anything clearly actionable here. Happy to reopen if others believe otherwise. With that said, I'd prefer a separate and clearer issue with a proposal be opened instead to make it easier for those wanting to contribute.