Gutenberg block settings not keyboard accessible at 200% zoom

[abrightclearweb]

Describe the bug
At 200% zoom, the block settings panel is not easily keyboard accessible.

The relevant WCAG 2.0 success criterion:
1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)

To Reproduce
Steps to reproduce the behavior:

1. Create a Gutenberg post with several blocks.
2. Focus on one block e.g. a Paragraph block.
3. Go to the Block Settings.
4. Attempt to change e.g. the text size in the Block Settings panel.

Expected behavior
I expected that Block Settings would be visible at 200% zoom. It was not and I had to toggle it again. I would have expected to see it after the Editor pane.

When I tried to access the Text Setttings controls for my chosen block, the keyboard focus cycled through the previous blocks in the post instead.

Even if I had been able to access them, it would have been difficult to know which Paragraph block text size I was changing if there were more than one. In a large document, this would be almost impossible.

Screenshots

This is how the paragraph text size can be set at 100% zoom using the keyboard (in this gif, I used the mouse to add the cursor to the Paragraph block for speed).

This shows the zoom size for the previously edited Paragraph block increasing to 200%. When I attempt to access block settings now, I start focusing on the other blocks ahead of the Paragraph block and their controls. I cannot access the Block Settings controls.

Desktop (please complete the following information):

• OS: Windows 10 64-bit
• Browser: Firefox Quantum
• Version: 61.0.2
• Gutenberg 3.7.0

[talldan]

The block toolbar changes to being displayed below the block when the mobile breakpoint is triggered (as in your gif).

However, to access the toolbar you'd still have to use shift+tab as though it was displayed above the block like this:

[anevins12]

Just slipping in that things need to be 400% accessible with WCAG 2.1.

[afercia]

Discussed during today's accessibility bug scrub while looking at #12104 which seems a duplicate.

Usually, users who need a very high "zoom in" level use screen magnifier software. These tools shouldn't trigger the behavior that moves the More Options button to the bottom. The WCAG ask for text to be zoomable up to 200%. This is not text, it's an UI control.

However I'd agree with @talldan, the real a11y issue here is that visual order doesn’t match the DOM order (which is a WCAG requirement). Worth considering a good percentage of users with accessibility need use their mobile device connected to a keyboard: https://webaim.org/projects/screenreadersurvey7/#mobilekeyboard

[afercia]

Re: the 200% zoom part, see also #12104

[afercia]

Reading again this issue, we're mixing two different things: Sidebar and Block toolbar.

Sidebar

(as originally reported by @abrightclearweb)

The root cause is no different from what happens in the desktop view. For keyboard users there's no easy way to jump from a selected block to the sidebar and keep the block selected. This is one of the main accessibility issues reported in the accessibility report. Currently discussed in #13663. See also #11581 and other previous issues and PRs.

At 200% zoom the problem is more evident. When the responsive view kicks in, the sidebar takes over the available width:

• use the keyboard
• press "Settings" in the top bar
• the sidebar opens and covers the post content
• (notice in the screenshot below while testing this, the selected block is a paragraph)

However, focus is not moved to the sidebar. See discussion on #13663 about why focus should not be moved automatically. At this point, tabbing again from the Settings button navigates to the post content, which is hidden behind the sidebar.

• tabbing selects a different block (see in the screenshot below, I'm now tabbing in a heading block)
• the post content is hidden: as a keyboard user I have no idea what's going on
• the tooltips of the various blocks UI appear on top of the sidebar, producing an interesting effect

Technically, it's still possible to use the Ctrl + backtick shortcut to navigate through the main editor areas, but the post content is hidden and the interaction is terribly confusing. Since the sidebar behaves like a sort of "modal", I'd expect a different interaction.

Whether the responsive view kicks in because users use a high zoom level or because they use a mobile device, the interface should still be operable with a keyboard. Worth also reminding many screen reader users use a keyboard when using their mobile devices.

Block toolbar

(as commented by @talldan and I)

This is a separate problem, sorry if I derailed a bit misinterpreting the original report. It is a problem because the visual order doesn’t match the DOM order. In the responsive view, tabbing with the keyboard through the block and its UI controls (including the toolbar) is a very confusing experience. I'm going to create a separate issue.