Skip to content

Audit the new Inserter accessibility #24975

@afercia

Description

@afercia

Describe the bug

The new Inserter introduced in WordPress 5.5 has been identified by the accessibility team as a regression in the accessibility level compared to WordPress 5.4. See #22858. The team asked, at the very least, to re-introduce a modal behavior which has been implemented in #24429 🎉 That means the Gutenberg plugin is now "fixed" for what concerns constraining tabbing within the Inserter but worth reminding the version shipped with WordPress 5.5 isn't "fixed".

Besides the welcomed re-introduction of constrained tabbing, there are outstanding issues that still need to be fully evaluated for their impact on accessibility and, to some extent, on general usability.

In the screenshot below: on the left, the new Inserter and on the right, the one in WordPress 5.4:

Screenshot 2020-09-01 at 15 50 25

Some of the things to evaluate:

  • the way the toggle button itself announces the Inserter and set expectations on the interaction: the button has an aria-pressed=true/false attribute and no aria-haspopup attribute, which doesn't seem correct to me
  • the Inserter is now a sort of sidebar instead of a floating panel (a "popover")
  • it isn't placed in the DOM immediately after the control that opens it: this is no different from other sidebars and from the previous popover implementation but it's still an a11y anti-pattern
  • it uses a role=region and an aria-label like the other sidebars so it's now also an ARIA landmark region
  • the keyboard shortcut to navigate through the regions (Ctrl+backtick on macOS) doesn't work: the Inserter closes when navigating away from it because of the issues outlined in Make the inserter behave as a popover #24429
  • the ARIA landmark is labelled "Block library" while all the other landmark labels are prefixed with "Editor" with the specific purpose to distinguish them from the other admin landmarks, e.g. "Editor top bar", "Editor content", "Editor settings"...
  • the inserter has now three main tabs: Blocks, Patterns, Reusable (note on language: they're respectively a noun, another noun, and an adjective)
  • the content of the three tab panels uses different design and interaction: IMHO this doesn't help a predictable, consistent, experience for users
  • specifically to the Block panel:
    • the expandable sections (disclosure widgets) are gone
    • all the available block types are now displayed in a long list: by default it's almost 70 types
    • while I do understand some of the reasoning behind this change, I'm not sure having such a long list to scroll is an improvement over the previous implementation
    • also, plugins may add more block types thus making the list even longer
    • by default, the "Most used" section is gone: IMHO this was very useful (it can be re-enabled in the editor Options, see "Enable the Most Used Blocks category in the block library"
    • keyboard navigation through the block types is made easier by the fact only one block type within a group is focuasble at a time: the other ones can be navigated via arrow keys
    • while there are ARIA widgets that are expected to use this keyboard navigation pattern, each group uses a role=listbox that doesn't seem correct to me: this role was used only to make screen readers announce the number and positions of the block types but it's arguably a correct role for this UI
  • specifically to the previews displayed on hover:
    • "Blocks" and "Reusable" show their previews in a fly-out that appears on the right
    • "Patterns" show the previews within the buttons that add the patterns
    • IMHO, this inconsistency adds a lot of cognitive load and it's an accessibility issue: it would be better to have the same preview mechanism for all the content, since it's basically the same UI
  • specifically to the Patterns:
    • it's a very long list as well, also considering that plugins and themes can add their own patterns
    • since the buttons contain the previews, the list is somehow very difficult to parse visually, not to mention the buttons big size contributes to make the list very long to be scrolled
  • more issues that may be added by the team during the audit

Marking this issue as bug because some of the points above need to be fixed. Adding also the "Task" label, pending a more thorough accessibility audit.

Metadata

Metadata

Assignees

No one assigned

    Labels

    [Focus] Accessibility (a11y)Changes that impact accessibility and need corresponding review (e.g. markup changes).[Type] BugAn existing feature does not function as intended[Type] TaskIssues or PRs that have been broken down into an individual action to take

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions