Build drag-and-drop reordering that works without a mouse

You are implementing drag-and-drop reordering for a list of items. The pointer-based drag interaction is only half the requirement — you are equally responsible for a keyboard-operable path that produces the identical reordering result, and for announcing what happened to assistive technology, since a drag gesture by itself is invisible to a screen reader and unusable without a pointing device.

LIST
A list of 12 dashboard widgets a user can rearrange to customize their layout.

DRAG-AND-DROP APPROACH
dnd-kit, already a dependency elsewhere in the app for a different drag-and-drop feature.

KEYBOARD REQUIREMENT
Must fully match WCAG 2.2 AA — keyboard users must be able to reach the same final states a mouse user can.

ITEM COUNT
Usually 8 to 15 widgets; never more than 30.

IMPLEMENTATION RULES
If using native HTML5 drag-and-drop, be aware of and account for its real, documented limitations before building on it: it has inconsistent and generally poor support on touch devices, no built-in keyboard interaction at all, and famously fiddly default drag-image and drop-effect behavior across browsers — most of these limitations are why a dedicated library is usually the better default for anything beyond a quick desktop-only prototype. Implement the keyboard path as its own, real interaction, not an afterthought bolted onto the pointer path: focus an item, press a designated key such as Space or Enter to pick it up, use arrow keys to move it up or down the list while it's picked up, and press the same key again to drop it in its new position — this is a documented WAI-ARIA design pattern for reorderable lists, not an invented convention, and it must produce exactly the same final order a pointer drag would produce for the same move. Announce every state change to assistive technology through an ARIA live region — when an item is picked up, when it moves to a new position during either pointer or keyboard interaction, and when it is dropped — stating the item's name and its new position out of the total count, since none of this is otherwise perceivable without sight. Persist the reordered result the same way regardless of which interaction method produced it — the backend or state update must never know or care whether the reorder came from a pointer drag or a keyboard move. Use aria-live="polite" rather than "assertive" for the position announcements unless the reorder is the sole focus of the whole screen, since an assertive live region interrupts whatever the screen reader is already announcing, and a rapid sequence of arrow-key moves through an assertive region produces a jarring stream of interruptions rather than the calm running commentary a polite region provides.

OUTPUT FORMAT
1. The pointer-based drag implementation, as real code, naming the library or native API used and why.
2. The keyboard-operable implementation, as real code, showing the pick-up, move, and drop key bindings.
3. The live-region announcement logic, showing the exact text pattern announced.
4. Confirmation that both interaction paths call the same underlying reorder function, so the persisted result cannot diverge based on input method.