[QTI] Improve accessibility of option reordering in QTI Choice and Ordering interaction editors

[AlexVelezLl]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Target branch: unstable

Observed behavior

Both the Choice interaction and Ordering interaction editors in the QTI editor let authors reorder answer options via move-up/move-down icon buttons (we will introduce a d&d handler later, but keeping this issue open as a reminder to check these things). Reordering is keyboard-operable via these buttons, which is a good foundation, but several accessibility gaps remain:

• Choice interaction's option list has no list semantics. ChoiceInteractionEditor.vue renders options as <div class="choices-list"> containing <div v-for="choice" class="choice-group"> rows — there's no <ol>/<li> structure, so screen readers can't convey list size or an option's position within it (e.g. "item 2 of 5").
• Ordering interaction already does this correctly — OrderingInteractionEditor.vue uses <ol class="items-list" :aria-label="..."> with <li v-for="item" class="item-group"> rows — and should be the reference pattern for Choice to adopt.
• Neither editor announces the result of a reorder to screen reader users. Clicking "move up"/"move down" changes the visual order and the position badge, but nothing is communicated via a live region.
• Focus is lost after a reorder. Confirmed by testing: clicking move-up/move-down does not keep focus on the button for the item being moved — it should remain on that button (now at its new position) after the list re-renders.

Expected behavior

• Choice interaction's option list uses semantic <ol>/<li> markup (matching Ordering interaction's existing pattern), so screen readers convey list size and each option's position.
• After a move-up/move-down action, a live-region announcement communicates the new position (e.g. "Option moved to position 2 of 5").
• After a move-up/move-down action, focus remains on the button for the item that was moved (now at its new position), rather than being lost.

User-facing consequences

Screen reader and keyboard-only users authoring QTI questions cannot reliably tell whether a reorder action succeeded or where an option landed, and may lose their place in the list after each move — making it difficult or impractical to define and verify answer/option ordering without sighted confirmation. This affects content creators with visual or motor impairments using Studio's QTI editor.

Context

• Related PR: feat: add Ordering Interaction Editor #6089 (adds the Ordering interaction to the QTI editor)

Acceptance Criteria

• Choice interaction's option list uses <ol>/<li> markup (matching Ordering interaction's existing structure), so screen readers convey list size and each option's position within it.
• In both editors, activating a move-up/move-down button triggers a live-region announcement of the option's new position (e.g. "Option moved to position 2 of 5").
• In both editors, focus remains on the move-up/move-down button of the item that was just moved (now at its new position) after the reorder — it is not lost.

AI usage

Used Claude Code to investigate the codebase and draft this issue from my initial observations; I reviewed and edited the content, confirmed the focus-loss behavior myself through testing, and directed the acceptance criteria scope.