Improve a11y of Block Card title in Inspector Controls

[getdave]

In the Issue below we identified that it was not possible to use user-focused Playwright selectors to select the block title in the block's inspector controls.

This is a code smell which indicates that the panel is likely not as accessible as it could be. For example the block card is the "title" for the entire panel and uses a h2 selector, but all of the controls in the panel also use h2 which means there is little or no hierarchy present.

Moreover, nothing semantically identifies the Block title as the title for the entire panel.

---

I'll add a comment. I'm not sure we used test ids before.

Originally posted by @youknowriad in #65819 (comment)

[getdave]

cc @kevin940726

Also @jeryj might have a suggestion for how we could improve the a11y here.

[kevin940726]

Maybe all we need is to ensure all other headings in the panel are below a level 🤔? c.c. @afercia for suggestions 🙇.

I'm not sure, maybe the current hierarchy is fine. We could change the test so that it checks for the first level 2 heading, and/or we could add some accessible text to indicate that the heading is the block's name.

[afercia]

See related #65238

The new design of the Post Summary changed the panel heading to be the title of the edited object. I'm not sure that's a great idea in the first place. As an user I don't need to see the title of the post (or other object being edited) there.

Any section of content should be clearly identified by a heading to communicate what the section is about. For posts, this is the Post Summary. The whole panel should be titled accordingly. Same applies to other edited objects. A generic title like 'Summary' could work for all cases. To me, the panel should have a visible 'Summary' H2 heading. All the other pieces of information within the panel should have H3 headings.

The headings hierarchy in the screenshot below doesn't help cleaerly identify the different sections of content. I think the design should be changed in the first place.

[afercia]

For comparison, this is the headings hierarchi in WordPress 6.5, and it was way better:

[getdave]

Thanks for the feedback. I agree that (the document title aside) the panel is not well formed as it currently stands. I also appreciate the efforts you went into to document this and other concerns in #65238.

I believe that as the design of much of the panel (with the exception of what you noted) has been established for some time, it will make it easier if we aim to make incremental improvements here. This will allow us to improve the situation for users of assistive tech and lay the groundwork for possible future changes to the visual design (if required).

Therefore, I would propose the following:

• Add an h2 heading (visually hidden for now) to each panel "Tab" (e.g. Post and Block) to describe the contents of the panel.
• Modify the panel headings (e.g. Style, Layout, Color...etc) to use h3 heading levels to reflect that they are sub sections within the panel.
• Modify the BlockCard component:
  • Visually hidden h3 title of "Block Information"
  • Use a definition list for the block name and description.
  • Retain existing visual presentation.

It could look something like this:

We should make similar improvements to the Document tab (i.e. the Post section of the sidebar) as per your reference screenshots above which show that the previous heading hierarchy was better. I'm suggesting that this does not mean we necessarily have to revise the visual design but rather reinstate the heading hierarchy in a semantic fashion.

I appreciate that usage of VisuallyHidden titles is probably not ideal. However, it will be easier to land improvements if we retain the existing visual presentation, at least in the short term.

I'm keen to understand what you think about finding a way forward along these lines.

[afercia]

I appreciate that usage of VisuallyHidden titles is probably not ideal. However, it will be easier to land improvements if we retain the existing visual presentation, at least in the short term.

Thanks @getdave a temporary improvement is better than nothing. I'd appreciate a follow-up and a discussion with the design team to stress, once again, the importane of providing semantic, accessible, design. I expect the design to be accessible in the first place. Removing heading isn't the best way to provide an accessible and usable UI. As you mentioned, visually hidden headings are only a partial improvement. Visible heaedings help all users.

Use a definition list for the block name and description.

Quick note: I'm not sure a <dl> would actually help. While it would be semantically correct, in practice it wouldn't be that useful. Most screen readers announce definition lists as normal lists and some screen readers even mess up with the list item counts. See the poor support at https://a11ysupport.io/tech/html/dl_element

[getdave]

Thanks @getdave a temporary improvement is better than nothing.

I think we should try it. If we can also improve the visual design at the same time then so much the better.

Use a definition list for the block name and description.

Ok noted. Thank you. So it would be better to just use <p>? I was even considering a table but that seems heavy handed.

I'd appreciate a follow-up and a discussion with the design team to stress, once again, the importane of providing semantic, accessible, design

I wonder if we need to improve our Design guidelines?

@WordPress/gutenberg-design may already have something in place. But as the project gets larger it's helpful to have guide rails in place to ensure all designs consider wider a11y considerations. I know the design team do consider this, but as humans it's easy to make mistakes and thus written guidelines might help ensure consistency.

[jasmussen]

It is unclear how incorrect semantics can be the sole responsibility of the design team. I would appeal to all of us lifting together, rather than singling out any one group or team.

[getdave]

Sorry if I was unclear in the comment above. I'm ruminating about potential solutions to help everyone and to improve the quality of our code.

I don't expect this to fall solely on design. That's unreasonable and untenable.

What I meant was if developers implementing the design had a list of checks we might be able to catch changes that inadvertently introduce changes that impact optimal a11y.

That said, it's going to be very difficult to codify best practise here as all scenarios are different.

[afercia]

I would appeal to all of us lifting together

That would be very appreciated. Accessibility specialists in this project are asking since years to be involved in the early design process because accessibility needs to be baked in since the design phase, but that's not happening. I see the design team proceeding autonomously often not taking into account functional analysis or semantics or accessibility concerns and instead prioritizing visual appearance, which I would argue isn't the best way to provide users with an usable and accessible UI. I would like to remind everyone that, for example, some parts of the Post summary redesign have already been reverted and other are planned to be reverted after direct users feedback, which proves the redesign process wasn't ideal. This isn't to blame anyone. To me, it's the process as is that just doesn't work.