-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Data Views] Updating keyboard navigation in list layouts #59637
Conversation
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
The design of the List layout will likely change a bit for 6.6 but this seems like a solid improvement regardless. Did you consider making the up/down presses select the item instead of just focussing it? |
Thanks for working on this! Current interaction sounds good, though select as Jay mentioned may be nice to try. I'll review the code tomorrow.
I couldn't reproduce in trunk 🤔 Gravacao.do.ecra.2024-03-07.as.18.21.29.mov
This happens in trunk and can be addressed separately. |
I've looked at the aria patterns and
|
Summary of roles & interactive elements 👍 <ul role="grid">
<li role="row">
<div role="gridcell">
<Button>Main content of the list item</Button>
</div>
<div role="gridcell">
<div role="button">Details button</div>
</div>
</li>
</ul> |
const shownData = useAsyncList( data, { step: 3 } ); | ||
const usedData = deferredRendering ? shownData : data; | ||
const selectedItem = usedData?.findLast( ( item ) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This changes how selection works for the list item. Particularly, in the case of some items being pre-selected from a different view and then switch to the list view.
Before:
Gravacao.do.ecra.2024-03-08.as.14.31.42.mov
After:
Gravacao.do.ecra.2024-03-08.as.14.30.12.mov
Until we figure out whether it makes sense to have multiple selected elements in the list view, this is a good approach.
{ usedData.map( ( item ) => { | ||
const id = getItemDomId( item ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not using getItemId
directly? By definition, that's each item's unique identifier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something related to how Composite/Ariakit works? Otherwise, I don't follow what the ids are for at this level. Judging by what I see at runtime, I presume 1) Ariakit needs this tracking and 2) we want to make sure the id
doesn't conflict with any other. If so, can we go simpler and do something along the lines of list-item-${getItemId( item )}
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm largely unfamiliar with Ariakit's Composite, but I find it weird that it 1) uses DOM ids to track the items and 2) the concept of a store attached to a component.
I understand that, by using Ariakit's Composite, we want to hide a certain layer of complexity (handle onClick/onKeydown events + tab/arrow-key mechanics) though I'd argue that complexity is familiar for most people while the complexity added by Ariakit's Composite mechanics is unfamiliar for most. In terms of maintenance and evolution of this code, I feel a bit uneasy about this trade-off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Asked around to some folks and others think this is fine.
Code-wise, this is ready in my view. The only thing I'd like a second opinion on is the use of Ariakit's Composite. If we go that direction, this is ready to land. |
bbb4e40
to
e179975
Compare
I've rebased the PR and set it to auto-merge when tests pass. I have upcoming work on selection that I want to base on this PR. Thanks for your work here, Andrew! |
Size Change: +414 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
What?
Adds grid semantics to the list layout, and makes use of
aria-labelledby
andaria-describedby
in list items.Why?
The list layout currently presents as a long list of buttons, each its own tab stop, which makes it difficult to reach the associated panel content. This is further complicated when grid items have additional detail buttons, doubling the number of tabs stops. Changing the list to a grid, and supporting Up/Down key navigation, means we can reduce the list to a single tab stop, providing easier access to the associated content.
Using
aria-labelledby
andaria-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.How?
Composite
component family has been used to add arrow key navigation to the list and list items.aria-labelledby
andaria-describedby
respectively.Testing Instructions
List layouts should not visually be any different, and behaviour should continue as before.
Testing Instructions for Keyboard
Issues
postId
is given as search parameter)