Improve the Document Overview panel accessibility

[afercia]

Description

Follow-up to #44788

The List view, Document information and outline have been merged within a single panel: the 'Document Overview'.
There are a few accessibility issues that were discussed in #44788 that need improvements. Other accessibility issues pre-date before the refactoring.

In short:

• Initial focus goes to the list view. That's not great, as the 'tabs' before the list view are skipped. Initial focus should go to the first focusable element within the panel.
• The DOM order and visual/tabbing order of the 'tabs' and the Close button doesn't match. The Close button is the first in the source but it's visually presented last.
• The 'tabs' aren't real ARIA tabs. They should use a TabPanel for better accessibility. See also TabPanel: add support for manual activation of tabs #45390 but i'm not sure that is a dependency as I'm not sure manual activation of the tabs is really needed here.
• On a post with no blocks (e.g. a new post), the List view ie empty. It should have at least some descriptive text.
• On a post with no headings, the Outline panel shows an image representing a headings hierarchy and some descriptive text. Personally, I find the image confusing and I'm not sure it's really needed. Actually, I tried to click one of the headings in the image because they look like the actual interactive interface.
• The info about the amount of words and characters lacks some semantics. Previously, it was at least using an unordered list. Now, it's a series of div and span elements.
• The info about the amount of words and characters is placed at the bottom of the sidebar. As such, it's hard to find for vision impaired users. The font size is also way smaller compared to the previous version, which makes this info even less discoverable. Previously, it used bigger font sizes (and some bold text).

/Cc @ciampo @jameskoster @alexstine

Step-by-step reproduction instructions

• Edit a post
• Click on the Document Overview button in the top bar
• The Document Overview panel opens
• See that initial focus is set to the list view.
• Note: on a new post, where the list view is empty, focus stays on the toggle button that opened the panel. Keyboard users would have to tab through several elements before they can reach the Document Overview panel. Screen reader users wouldn't have a clue what the button did.
• Other issues need manual exploration of the source. See also attache dscreenshots.

Screenshots, screen recording, code snippet

Initial focus is set to the wrong place:

List view is empty on a new post:

Characters / Words info less readable (and thus less accessible)

compared to the previous version:

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[afercia]

Note: I do realize the 'tabs' not really ARIA tabs are inspired by the similar tabs the Settings sidebar e.g. Post and Block. That's not a standard implementation. At that time we thought that using an ARIA tabs pattern for just two tabs was, in a way, overkill and maybe not efficient. From a keyboard interaction perspective, tabs make totally sense when there's a lot of tabs. When there are just two tabs, maybe is faster and more efficient to not use an ARIA tabs pattern. However, kayhe it's time to revise that decision. As discussed in other issues, the TabPanel component is going to be improved and used in more places so there's.a greater value in using it as a standardized, consistent, interaction model.

[ciampo]

also cc @ntsekouras

[alexstine]

Initial focus goes to the list view. That's not great, as the 'tabs' before the list view are skipped. Initial focus should go to the first focusable element within the panel.

We cannot do that because of a couple cascading events.

1. The ListView has a role="application" wrapped around it to prevent NVDA from switching in to browse mode when it encounters the options button in the TreeGrid component.
2. Even if the correct ARIA role is used, NVDA suffers from a bug where a qualifying browse mode element will still force the mode to switch even if it should not. The only work-around right now is to use the application role or else you would have to use non-semantic elements to avoid triggering accessibility APIs which would make the problem worse, not better.

• NVDA doesn't toggle browse mode off when focus is moved to an interactive list nvaccess/nvda#13221 (comment)
• Drag and drop on the web requires focus mode when HTML buttons are focused nvaccess/nvda#14084

3. Because of the above bugs, it is better to focus the ListView straight away as NVDA behaves better this way. I am not a huge fan of it either but I also do not see another way. Trying to interact inside and outside the application role is tricky.
4. If this solution is adopted for the new block navigation mode, it will be much easier to place the focus on mount vs. on the tab only when the global shortcut or button are used.

On a post with no blocks (e.g. a new post), the List view ie empty. It should have at least some descriptive text.

Agreed. This was also confusing to me. I attempt to fix it by returning null on the component, but I agree a message would be better. Maybe Gutenberg design team can weigh in.

#45135 (comment)

In the above PR, I am working hard to make the shortcuts more useful for users. I just can't do much when I do not have lasting help. Contributors get pulled off to go work on "other important parts of the project" and I am left with PRs I want to land but have little hope of finishing. React is not really a blind friendly language in the way of E2E testing. Bugs need to be caught visually.

Thanks.

[alexstine]

Most of the issues brought up here have now been fixed. We should now have support to focus the tab panel now that it uses real tabs vs. the fake button tabs. I propose closing this in favor of a follow-up with clear instructions on how to move forward since this issue now contains out of date info.

Thanks.

[ciampo]

FWIW, we're also working on a new version of the TabPanel component that will allow greater flexibility when implementing tabs, which should help us to remove all remaining examples of poorly-implemented tabs