Adding in progress so it's not merged by mistake.

Rebased on latest master.

I've just tested again this PR with Firefox and NVDA and the role=application does have a huge impact.

It is expected that role=application makes screen readers stop intercepting key strokes (this would actually solve some issues in Gutenberg). It is also expected that it makes tabula rasa of all the semantics within the element with role=application.

What I wasn't expecting is that, when inside the element with role=application, also the semantics of anything that is outside is not perceived at all. This means that, when operating inside the blocks, no semantics in the general layout, top toolbar, sidebar, etc. is perceived at all.

For example, when invoking the Elements List in NVDA there are no landmarks any longer. No headings at all. Navigation through headings and landmarks doesn't work. Potentially, any other screen-reader specific shortcut to navigate through content doesn't work at all.

Screenshot without role=application: I'm on a button in browse mode and the Elements Lists shows me all the landmarks:

Screenshot with role=application: I'm on a button in browse mode: no landmarks except a footer (not relevant, it comes from embedded youtube video which has a div with role="contentinfo" and it's perceived because it's within an iframe):

Basically (and considering just these two side-effects) there wouldn't be no way for screen reader users to jump from the blocks to the top bar or to the sidebar, which is essential to be able to operate on the blocks.

I haven't tested other potential side-effects but potentially there's a lot of them that could break interaction in a so severe way to make impossible to use the editor.

Is there still a relevancy / desire to continue the work here?

This PR was mainly for testing purposes, the accessibility team wanted to test the behavior of assistive technologies when switching everything to role=application. Can be closed.