The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you’re merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>

To understand the WordPress project’s expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +1.07 kB (+0.04%)

Total Size: 2.54 MB

_{compressed-size-action}

Should we have similar navigation to DataViewsPicker. Was there specific reasons for having a listbox even if it displays a grid?

Listbox is more semantic for the picker component because it’s specifically meant for lists that can be selected from, and also it may have better screen reader support than grid. There was a whole discussion on the PR that implemented it, starting here 😅

I agree that the arrow key navigation using only left and right keys isn’t ideal for the visual grid though. This might be one of those issues where there’s no perfect solution.

VoiceOver is also reading out both the “row” role and the aria-label for each row, so it goes “row Row 2”.

That’s weird because I have tested only with VoiceOver and as you can see in the video of the description, it says row 2. Also, in order to do that I had to also add the aria-label Row ${rowNumber}, where I believe I shouldn’t and the role="row" should handle that. Without it, it would announce row: ${first label found from the first item of the row}.

I would like to be able to use the title field for the aria-label, but I don’t think the titleField is a required field. Any ideas?

Maybe use the title as an aria-label when it exists, else don’t add an aria-label. That way it’s up to consumers. It’s probably best practice to always have a title, even if it’s not shown visibly. I seem to recall it’s also still used for aria-labels when not visible. @andrewserong might know more specifics, as he did some past work on titles for grid.

Could we maybe use aria-hidden on the title button because it duplicates the image button in functionality? And remove it as a tab stop too.

I’ve been researching for a while how (and if we should) remove some nested aria-labels to prevent them being announced when focusing the gridcell. I haven’t found a good solution so far and probably we shouldn’t do that, based on this. A small quote from that is:

The distinguishing feature of grid that enables it to be used for grouping other widgets is that its cells are containers that preserve the semantics of their descendant elements. That is, grid cells do not override or suppress the semantics of the elements they contain.

Is it possible to apply explicit aria-label? For example, in the Notes feature, we recently applied explicit aria-labels to treeitem:
I would like to be able to use the title field for the aria-label, but I don’t think the titleField is a required field. Any ideas?

I tried that with const itemLabel = titleField?.getValue?.( { item } ) || __( '(no title)' );. We have the same handling for DataViewsSelectionCheckbox, so it should be fine, but it still announces all the nested elements.

I’ve asked again for a review in core a11y channel and hopefully we get some more feedback.

My screen reader reads out all the content inside the grid items, and I’m not sure if this is acceptable for accessibility, but I find it very annoying:

By the way I think that’s the expected behavior (to also announce the text inside the gridcell) for users to know what’s in there.

My screen reader reads out all the content inside the grid items, and I’m not sure if this is acceptable for accessibility, but I find it very annoying:

It occurred to me that a similar approach to the List layout could be applied to the Grid layout. See: #59637

Using aria-labelledby and aria-describedby on list items allows us to reduce the information density, such that each item only presents with the primary field as a title, with the other fields available as additional descriptive content. This means that information can be scanned much faster.

That is, use the aria-labelledby and aria-describedby attributes to apply appropriate information to grid cells 🤔

It occurred to me that a similar approach to the List layout could be applied to the Grid layout. See: #59637

That is, use the aria-labelledby and aria-describedby attributes to apply appropriate information to grid cells 🤔

I explored this, but I’m not sure it’s the same use case.

List layout:

• has fields outside of gridcell and needs aria-describedby to add additional information to screen readers
• it has one interaction (select the element) and actions are built as part of table layout (each row is the title, primary action, actions toggle).
• it does not have other interactive elements nested in the gridcell.

Grid layout:

• has multiple interactions like the `selection checkbox, media item is (conditionally) clickable
• for complex gridcells like this, I think it’s better to have the content inside the gridcell (not like list) and users could tab inside each cell (as it’s right now). If we moved the content outside it would break the interaction model.

This makes me wonder how list layout will behave if we have fields that render an interactive field. I didn’t test, but it seems it will not be best for a11y. Also, I’m curious why in list we skip the actual description field from the description announced.