Skip to content

fix(settings): make codec priority reorderable by keyboard and touch - #743

Open
czoli1976 wants to merge 3 commits into
developfrom
fix/codec-priority-keyboard-touch
Open

fix(settings): make codec priority reorderable by keyboard and touch#743
czoli1976 wants to merge 3 commits into
developfrom
fix/codec-priority-keyboard-touch

Conversation

@czoli1976

Copy link
Copy Markdown
Contributor

What is this PR doing?

Makes the codec priority list in Settings → Video reorderable by keyboard and on touch.

The list was HTML5 drag-and-drop only — no key handlers, no ARIA, no touch path:

// AdvancedSettingsCodecPriorityField.tsx (before)
<li
  key={codec}
  draggable
  onDragStart={}
  onDragEnd={handleDragEnd}
  onDragOver={}
  onDrop={}
>

Two consequences:

  • Keyboard users cannot reorder the codecs at all. There is no focusable control and no key
    handler anywhere in the field — a WCAG 2.1.1 Keyboard (Level A) failure.
  • The control is inert on touch. HTML5 drag events are not synthesised from touch input, so on
    phones and tablets — where this dialog renders full-screen — the setting can be read but never
    changed.

This adds a Move up / Move down button to each row, disabled at the ends of the list, each
with a translated aria-label naming the codec it acts on ("Move VP9 up"). Both delegate to the
existing pure reorderCodecPriority helper, so ordering behaviour is unchanged and there is no
second implementation to keep in sync:

const moveCodec = (codec: AdvancedSettingsVideoCodec, offset: -1 | 1) => {
  const targetCodec = codecPriority[codecPriority.indexOf(codec) + offset];

  if (!targetCodec) return;

  setCodecPriority(reorderCodecPriority({ codecPriority, draggedCodec: codec, targetCodec }));
};

Drag-and-drop is deliberately untouched, so mouse users lose nothing.

One piece of scope that is not accessibility. The field's data-testids were hardcoded, so the
component could only ever be rendered once per page. This adds an idPrefix prop (defaulting to
today's value, so nothing changes) to make a second instance addressable. That is groundwork for a
screen-share codec section; it is included here because it touches the same lines as the testids
above and would otherwise conflict.

New keys land in all five locale files in this commit, so localeParity.spec.ts stays green.

How should this be manually tested?

  1. Settings → Video → Codec → Manual to reveal the priority list.
  2. Keyboard only: Tab to a Move up / Move down button and activate it with Enter or Space. The
    codec should change position and the numbering update. On develop there is nothing to Tab to.
  3. Touch: on a phone, tablet, or device emulation, tap the buttons. On develop dragging does
    nothing at all.
  4. Mouse: drag-and-drop should behave exactly as before.
  5. The first row's Move up and the last row's Move down are disabled.

Verified manually in the browser across all four paths.

Known and deliberately out of scope

Flagged so they read as decisions rather than oversights:

  • No status announcement after a move. The visible order and the position numbers change, but
    nothing is announced to a screen reader (WCAG 4.1.3 Status Messages, AA). Worth adding an
    aria-live region, but it is a separate concern from the Level A keyboard failure this fixes.
  • Buttons are 28px. Above the 24px minimum of WCAG 2.5.8 Target Size (Minimum, AA), below the
    44px of 2.5.5 (AAA). Sized to match the existing row furniture rather than introduce a
    one-off.

What are the relevant tickets?

A maintainer will add this ticket number.

Resolves VIDSOL-

Checklist

[x] Branch is based on develop (not main).
[ ] Resolves a Known Issue.
[ ] If yes, did you remove the item from the docs/KNOWN_ISSUES.md?
[x] Resolves an item reported in Issues.
If yes, which issue? #739

The codec priority list was HTML5 drag-and-drop only, with no keyboard
handlers, ARIA roles or touch support. Keyboard users could not reorder the
codecs at all (WCAG 2.1.1), and because HTML5 drag events never fire on touch,
the control was unusable on phones and tablets - where this dialog renders
full screen.

Add per-item Move up / Move down buttons with descriptive aria-labels, disabled
at the ends of the list, reusing the existing pure reorder helper. Drag and drop
is untouched for mouse users.

Also add an idPrefix prop so the field can be rendered twice with unique test
ids, which the upcoming screen-share codec section needs.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@vonage-ai-assistant

vonage-ai-assistant Bot commented Jul 28, 2026

Copy link
Copy Markdown

AI Code: 0%

AI Adoption Report

Lines %
AI-generated 0 0%
Human 0 100%
Untracked 175
Total 175
Per-commit breakdown (3 commits)
Commit Message Added AI Human AI %
3102041 chore(i18n): move the Video section labels out of this PR 0 untracked
3e76d3a fix(settings): keep the move buttons focusable at the ends o 53 untracked
6a7b280 feat(settings): make codec priority reorderable by keyboard 122 untracked

Warning

The following commits have no Git AI authorship notes — AI adoption cannot be tracked for these changes.
Install git-ai locally (curl -sSL https://usegitai.com/install.sh | bash) to enable automatic tracking.

  • 3102041 chore(i18n): move the Video section labels out of this PR
  • 3e76d3a fix(settings): keep the move buttons focusable at the ends o
  • 6a7b280 feat(settings): make codec priority reorderable by keyboard

Powered by Git AI Standard v3.0.0 — authorship data from refs/notes/ai (supports sessions-v2 format)

czoli1976 and others added 2 commits July 28, 2026 13:15
The Move up / Move down buttons used the `disabled` attribute at the ends of
the list. Moving a codec to either end disables the very button that was just
activated, and the browser then drops focus from a disabled element to <body> -
verified in Chrome 148: focusing a button and setting `disabled` leaves
document.activeElement as document.body, while `aria-disabled` retains it.

So the final press of a keyboard-only reorder left the user with no focus at
all, and the next Tab restarted from the top of the dialog. That is a focus
order defect introduced by the very change meant to make this control keyboard
accessible.

Mark the boundary buttons `aria-disabled` instead. They stay focusable and in
the tab order while still announcing themselves as unavailable, and moveCodec
already no-ops at the bounds so pressing them does nothing. The disabled-state
styling moves from the `disabled:` variants to a conditional class.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
These three keys - advancedSettings.video.sections.camera.label and the two
screenSharing ones - were added here by accident. Nothing in the codec priority
field reads them; they belong with the change that introduces the Camera and
Screen Sharing section headings, and have been moved there.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant