Improve sortable list accessibility and remove drag-and-drop code

[joshsadam]

What does this PR do and why?

This updates sortable list interactions so keyboard and screen reader users can move, select, and reorder options with clearer focus feedback. It also removes old drag-and-drop grouping code that is no longer used, which makes the component simpler and less error-prone.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other pull requests.

How to set up and validate locally

1. Start the app with bin/dev.
2. Open http://localhost:3000/rails/view_components/sortable_lists_component_preview/two_lists and verify you can move focus with Tab, move between options with Arrow Up and Arrow Down, toggle selection with Space, add with Enter, remove with Delete, and reorder selected options with Alt+Arrow Up and Alt+Arrow Down.
3. Confirm focus styling is clearly visible on the active option in both light and dark themes, and confirm it stays visible after moving options between lists.
4. Open http://localhost:3000/rails/view_components/sortable_lists_component_preview/three_lists and verify list items are not draggable with the mouse, list behavior still works through buttons and keyboard, and no JavaScript errors appear in the browser console.
5. Check an empty-list state by moving all options out of one list and confirm that list remains focusable while add/remove/up/down buttons are disabled until a valid selection exists.

PR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the PR acceptance checklist for this PR.

[ksierks]

I was able to test the sortable lists through line list export, but the previews did not work for me.

[joshsadam]

I was able to test the sortable lists through line list export, but the previews did not work for me.

Thanks for finding that, fixed in 580f169

[ChrisHuynh333]

Unless this changed, I believe we made the explicit decision to make the disabled buttons focusable since W3C's listbox components' disabled buttons are focusable/tabbable
https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-rearrangeable/#ex2_label

[ericenns]

Unless this changed, I believe we made the explicit decision to make the disabled buttons focusable since W3C's listbox components' disabled buttons are focusable/tabbable https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-rearrangeable/#ex2_label

Yeah using aria-disabled is preferred instead of disabled as that way we can inform users that they need to select items from the list to be able to perform the action. That way they can discover the action whereas with disabled they are unable to discover the button with screen reader and know that they need to select data before they can perform the action.

[joshsadam]

Unless this changed, I believe we made the explicit decision to make the disabled buttons focusable since W3C's listbox components' disabled buttons are focusable/tabbable https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-rearrangeable/#ex2_label

Yeah using aria-disabled is preferred instead of disabled as that way we can inform users that they need to select items from the list to be able to perform the action. That way they can discover the action whereas with disabled they are unable to discover the button with screen reader and know that they need to select data before they can perform the action.

Sounds good, sorry @ChrisHuynh333 and @ericenns updated in e3bca2d