react-aria: useSelectableList - how to disable temporary?

[andreasheim]

We've devised a system where you tab from section to section, then press enter to drill down/activate the section, then can tab though the elements, and press esc to go back up a level.

To make this work, I need to disable the keyboard navigation for elements in each section. For regular elements, that's easy with tabIndex={-1}.

How can I accomplish this for a list built with useSelectableList? There doesn't seem to be a way to disable the list as a whole.

I seem to be able to mostly achieve it by marking all keys as disabled:

    let { listProps } = useSelectableList({
        ...props,
        collection: state.collection,
        disabledKeys: hasKeyNavScope ? state.disabledKeys : new Set(state.collection.getKeys()), 
        isVirtualized: false,
        ref: selectableRef,
        selectOnFocus: true,
        selectionManager: state.selectionManager,
    });

This works initially. The list is keyboard disabled. I can then activate the drill down mode, tab to the list, select an item.

However when I then press ESC to exit out, the selected item remains having tabIndex={0}, so breaking my system.

---

I can set tabIndex={-1} on each list item.

        <StyledItem
            role="option"
            ref={ref}
            {...itemProps}
            tabIndex={-1}
            style={{
                border: isSelected ? `2px solid red` : undefined,
                top: `${cardTop}px`,
            }}
            aria-selected={isSelected ? "true" : undefined}
        >
            {item.rendered}
        </StyledItem>

Surprisingly this works better, as something else is still changing tabIndex back to 0.

It's not quite a solution though.

Now I select the section, press enter, tab to focus the list, esc to exit, tabbing goes to next section. Tab back, enter, tab again, now the list is selected instead of the item. I tab forward, then back, now the item is properly selected again.

---

It seems like I'm rather close, just missing some little detail

[snowystinger]

Hey, thanks for the discussion. I’m not sure you’re using the right thing to accomplish what you want.

First off, useSelectableCollection, while publicly available, isn’t meant for general consumption yet. We’re still working out details with it, but we need it in many of our components and hooks, so it must be publicly available.

Second, I’m not sure what this system is that you’ve created. What aria pattern is it implementing? Or what component does it take inspiration from?
We currently use it in listboxes, menus (which are listboxes), pickers (which are listboxes), etc. Keyboard navigation is defined here https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/listbox_role#keyboard_interactions

In contrast, we’re currently working on ListView, which also has selection and allows for both selection and action on items. I’d suggest looking to this work as inspiration, which you can find in PR’s and much already committed to the repo here https://github.com/adobe/react-spectrum/blob/main/packages/%40react-spectrum/list/src/ListView.tsx
We are using the Mac Finder as our inspiration for much of how this works. The hooks aren’t quite ready for this one.

[andreasheim]

Thanks for the reply! I used it based on your presentation at axe-con. I know you mentioned there as well that it's not quite ready for public consumption.

I was considering ListBox, however I stopped when reading this

NOTE: listbox options cannot contain interactive content (e.g. buttons, checkboxes, etc.). For these cases, see useGrid instead.

useGrid though is also not yet in the public documentation.

What I'm implementing is a list of cards. Once a card is selected, further interactive elements become available.
I do see that ListView has more of what we're trying to do already implemented, and it uses useGrid.

---

I don't know if there is an aria pattern for what we're building on the parent of this list. Maybe I can best describe it as an extension of a skip links pattern, where the first tab will prompt you to deciding whether you want to go to the nav, or the main content.

On a page with many interactive elements, we now want to give the user the option to tab from section to section, then dive into the section they are interested in.

To achieve this, I would like to have tabIndex=0 only on the sections, and any interactive elements within using tabIndex=-1 until they press enter to interact with that section.

So I want to be able to prevent the entire list from receiving keyboard focus until that happens. We have this working with the more simple elements in a section (buttons, menu).

---

An alternative I suppose would be to programmatically move the focus from section to section. I thought I'd be able to avoid that. (Might have to create on what to do with the last section in this case)

[andreasheim]

I figured creating a standalone example would be the best way to figure this out. May take me a bit.

[andreasheim]

We've decided that most components probably won't have a way to turn keyboard access on and off. So we're now moving focus programmatically to siblings, and only allow focus to children when "activated". So it has made this a bit of a moot point for us.

---

I do have a separate question - let me know if I should start a new discussion.

You showed me ListView.tsx as a more/most complete example of what I'm trying to do.

It does use import {Virtualizer} from '@react-aria/virtualizer'; however that is not being exported - it's not part of the package. Are there plans to do so any time soon?

It does seem to add the essential task of moving focus to the parent element when the focused element is scrolled out of view, and then scrolling it back into view on focus.

[snowystinger]

Hey, sorry, I'm not sure I follow. '@react-aria/virtualizer' is a public package https://www.npmjs.com/package/@react-aria/virtualizer and it exports Virtualizer as a named export. https://codesandbox.io/s/sweet-engelbart-ylerv0?file=/src/App.js

[andreasheim]

Duh 🤦🏼 It's published individually, just not as part of the react-aria package.

[snowystinger]

Ah, I see the confusion there.
We haven't started documenting it yet, so we haven't added it to the mono package yet

[andreasheim]

@snowystinger I have a followup question. I've made quite some progress, though stuck on one thing.

Our list of cards are editable, so the text may turn into a textarea or input. This should be fine in a grid, right?

However, we noticed that when typing into the text field, the collator would intercept, and interpret that as search, and focus another item. We removed the collator, and most of that went away. Haven't dug in whether there's a way to configure that it doesn't do that when focus is on a textarea/input element.

However, even after removing the collator, there is still a weird thing about pressing space. If I press and release space quickly, it doesn't stick. Like a global event handler is still intercepting that. If I press a bit longer, then release, it works - the repeater shouldn't have kicked in yet.

I've looked a bit in usePress.ts, which may handle this, but it seems like isValidKeyboardEvent should make it ignore exactly this.

[andreasheim]

What would be the best way for an item in editMode to force a resize?

Our text field is auto-growing, so the height of the cell/row changes as you enter text.

The Virtualizer/VirtualizerItem doesn't seem to pick this up as you type. It does pick it up if I mouseOver/mouseOut its parent. That makes it apply/remove a class, so I suppose that triggers the layoutEffect in useVirtualizerItem.

[snowystinger]

I do not know off the top of my head and I'm unsure when I'd be able to dive into that, @devongovett have any gut reactions to this?
Might be easiest though to allocate a reasonable amount of space ahead of time and make use of textarea scrolling overflow for longer strings?

[devongovett]

virtualizer has an updateItemSize method, you can see it used in useVirtualizerItem. If you use that hook, it also returns an update function that you could call.

[andreasheim]

Thanks! We're following the ListView example, so we use the react-aria Virtualizer component. So we don't use that hook directly.

But it seems like I should be able to extract that - the actual measuring logic is small. Would item.key be the same as layoutInfo.key?

[devongovett]

Yes