search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.5k stars 4.2k forks source link

Gutenberg block settings not keyboard accessible at 200% zoom #9739

Open abrightclearweb opened 6 years ago

abrightclearweb commented 6 years ago

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). change paragraph text size 100 zoom

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. gutenberg block settings 200 zoom

Desktop (please complete the following information):

talldan commented 6 years ago

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: toolbar-keyboard

anevins12 commented 6 years ago

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

afercia commented 5 years ago

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 commented 5 years ago

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

afercia commented 5 years ago

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:

screenshot 2019-02-28 at 12 24 37

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.

screenshot 2019-02-28 at 12 29 36

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.