Opening a new issue for this since I think my issue is more general than it is technical. The premise is very simple. We can dramatically improve keyboard navigation for Gutenberg if we just fix a couple of basic things. Accessibility is a part of this, but right now it's just really hard and tiresome to navigate using the keyboard. This is primarily a usability issue.

Main keyboard navigation usecases that we need to support better:

• Navigating across blocks
• Navigating from a block to its settings and vice versa
• Discovering how these things are navigated using keyboard only

What do we need:

1. a way to navigate the blocks without going into them. Apart from just giving a far better UX, this would allow screen reader users to get an overview of the structure of their post and go in to edit the block they want to edit when they want to edit it.

• Relevant issue: Simplify keyboard navigation through blocks #5694. The whole thing is already almost fully conceptualized. We should just do it.
• Relevant try PR: Accessibility: Try adding the keyboard navigation/edit mode #5709. Turns out the things was even already almost entirely built. Let's just finish this and get it over with.

2. a way to navigate from the block to the block settings and vice versa. I would add skiplinks to each block to do this and have a shortcut to toggle between the block and its settings.
3. a way to discover how keyboard navigation works. I think having a skiplink at the beginning of the navigation which reads "Keyboard navigation manual" would do the trick. It could simply trigger the keyboard shortcuts modal extended with a section about how blocks can be navigated using keyboard. Will create a separate issue for that. This manual would not only be useful for screenreader users but also for regular users. Was explored briefly in User guide and keyboard shortcuts documentation #5420

Some thoughts on navigation and a11y

Navigation and screen reader accessibility go hand in hand. The way to discover what's on a page with a screen reader is simply to navigate through it's basic structure. To make a complex application accessible, we need a layered approach, where the top level structure is as simple as possible and deeper nested capabilities (like editing in a block) can be a layer underneath that. The main function of any top layer is always to provide a framework for orientation, thus navigation is a top level concern. Editing is not, even though it's the primary concern of the editor. In order to edit, it needs to be easy to navigate into editing. From a visual perspective this kind of conceptual hierarchy is actually also how a web page is processed by users. However, instead of explicit it is implicit, so there is less necessity to conceptualize it. I'm sure I'm reiterating here what others might have already expressed far more eloquently.