Size Change: +22 B (0%)

Total Size: 1.7 MB

_{compressed-size-action}

I'm not sure this should be done. The whole purpose of navigable regions is to make available to all keyboard users a feature that screen readers navigation provides for ARIA landmarks.

ARIA landmarks are meant to be used for the main sections of a page. Besides structural HTML tags that have native semantics of landmark (main, nav, aside, footer, etc.), some ARIA roles are mapped to ARIA landmarks. One of them is the role="region" which becomes an ARIA landmark only when it has an accessible name, which in most of the cases is provided by the means of an aria-label.

That said, all navigable regions in the editor are ARIA landmarks, so far. Screen readers provide dedicated ways to nqvigate through landmarks. For example:

• NVDA: the D key, or the Elements list window.
• Safari+VoiceOver: the Control+Option+Command+N keys (add the Shift key to navigate backwards) or the Rotor.

This is a very convenient way to allow screen reader users to jump through the main sections of a page, as long as all perceivable content of the page lives within landmarks. Screen reader users can just use the native screen reader tools to navigate landmarks.

The whole purpose of the navigable region feature was to make this native screen readers feature available to other keyboard users. Basically, it 'duplicates' the native screen readers feature. As such, the native feature based on ARIA landmarks must always match the equivalent Editor feature based on navigable regions.

Technically, we opted to use the role="region" because it's generic enough. Other markup elements that are native landmarks (main, nav, aside, etc.) wouldn't be appropriate. The role="region" must be labelled to become an ARIA landmark, so that native feature and editor feature match.

For example, this is treated like an ARIA landmark:

<div role="region" aria-label="Some meaningful label" tabIndex="-1">

This isn't:

<div role="region" tabIndex="-1">

So, we would need to label the region that wraps the toolbar to make it an ARIA landmark. And here comes the point:

ARIA landmarks are not supposed to dynamically appear and disappear from a page.

Instead, they are meant to mark the main sections of a page in a way that users can orient themselves, have an idea of the structure of the page, and navigate through these sections.

• User lands on a page.
• User learns the page is split in, for example, 5 landmarks.
• From that moment on, user knows there are 5 landmarks.
• User won't have any cllue that, at some point, one more landmark dynamically appears on the page or that one landmark gets removed. That would be very confusing and it's not the intended usage of landmarks.

The block toolbar appears and disappears, depending on the user flow. That would be an ARIA landmark that is added or removed continuously and that would defeat the purpose of a landmark.

One more important point:

The block toolbar lives in the main document, while blocks live in the iframed document. As such, screen readers (at least VoiceOver) will not detect the toolbar landmark when the block is selected because it lives in another document. WHen the block is selected, that's the moment where users would need to find the toolbar and this wouldn't work for native screen readers landmark navigation. It would only work with the Editor shortcuts.

I tested this by adding an aria-label to the toolbar region in this PR.

Screenshot: focus is in the iframed document (the block) and VoiceOver doesn't see any landmark:

Screenshot: focus is in the main document (the block toolbar) and VoiceOver sees all landmarks:

Okay, so I guess Voiceover landmark navigation is entirely useless period. If inside the iFrame, you couldn't even move to the sidebar as it is outside of the iFrame. Wow. 😞 Good thing we have the code to handle this already.

I guess we'll have to close this, I was totally unaware of the Voiceover bug with regions. I knew the appearing/disappearing would need to be a discussion later but we can't solve for Apple bugs.

We'll keep brainstorming in the other PR. There's a way to make this work, we'll find it eventually.