a11y: remove preset rails for backends and enable a global but merged solution

[fl0rianr]

Scope

• Area: prototype/ui-redesign/
• Milestone: GUI3
• Related issue: a11y: remove preset rails and introduce a completely new and elegant model view concept #2355
• Group F -> branch feat/gui3-forms-icons-a11y
  Grouped by component to avoid merge conflicts.

Task

Remove the preset rail and the visual preset selection flow from the Backend view.

A backend should not behave like a model in the UI. In the default case, a backend has no preset assigned. However, a backend may optionally receive a preset through the global preset management flow.

The assignment should happen in the global Presets view, where a preset can be assigned not only to a model, but also to a backend.

Expected behavior

Backend view

The Backend view should focus on backend configuration and backend status only.

The following should be removed from the Backend view:

• preset rail
• visual preset picker
• model-like preset selection UI

A backend should not appear as if it always requires or owns a preset.

If a backend has no preset assigned, this is the normal default state.

If a backend has a preset assigned, the Backend view should show preset name and icon like currently, but only affected backends and the preset assignment itself should not happen there.

Global preset assignment

Preset assignment should be handled centrally in the global Presets view.

In that view, users should be able to assign a preset to:

• a model (already there)
• a backend

When assigning a preset to a backend, the UI must make it clear that this assignment is global.

Example wording:

This preset applies globally to all models using this backend.

This is important because backend presets are not model-specific. Once assigned to a backend, the preset affects every model that uses that backend.

Backend preset semantics

A backend has no preset by default.

A backend preset is optional and is mainly intended for backend/runtime argument defaults.

Since every model already has a model preset, conflicts are likely when a backend preset is also assigned. This is expected and should be handled through the argument merging behavior supported in main.

The UI should therefore avoid presenting backend presets as an alternative to model presets.

Instead, the mental model should be:

• model preset = model-specific defaults
• backend preset = global backend/runtime defaults
• effective runtime arguments = merged result

Argument merging

Backend preset assignment is specifically intended to work with the argument merging support in main.

When both a model preset and a backend preset exist, their arguments should be merged into the effective configuration.

The UI should make this relationship clear and should not imply that selecting a backend preset replaces the model preset.

The final precedence and conflict handling should follow the existing argument merging behavior in main.

Acceptance criteria

• The Backend view no longer shows the preset rail

• The Backend view no longer shows the visual preset picker

• Backends do not appear to require a preset by default

• A backend can exist without any assigned preset

• Backend preset assignment is moved to the global Presets view

• The global Presets view allows assigning a preset to a backend

• The global Presets view allows assigning a preset to a model

• The UI clearly communicates that backend preset assignment is global

• The UI clearly communicates that a backend preset applies to all models using that backend

• Backend presets are treated as optional global backend/runtime defaults

• Model presets remain model-specific

• Backend preset assignment does not replace the model preset

• Model preset arguments and backend preset arguments are merged using the argument merging behavior supported in main

• Conflict behavior follows the existing argument merging semantics in main

• Programmatic semantics verified for screen readers:

  • roles
  • accessible names
  • states

• Keyboard operability verified where applicable

• Playwright/axe-core a11y tests cover the change

• All tests pass with npm test

• Progress and challenges recorded as comments on this issue

• PR opened against kpoin/ui-testing

Tracked by Squad. Assigned: @squad:mattingly (UI/Frontend), QA: Haise, review: Lovell.

[kpoineal]

Picking this up now (Mattingly, Squad). Plan: (1) Remove the preset rail + visual preset picker from the Backend view so a backend no longer behaves like a model — backends have NO preset by default, and the view focuses on backend config/status only; a read-only preset name+icon may remain if one is assigned. (2) Move backend-preset assignment into the global Presets view, mirroring the existing model-assignment flow, with clear copy that the assignment is GLOBAL (e.g. 'This preset applies globally to all models using this backend'). (3) Keep backend-preset binding client-local (linkedPresetId pattern, invariant #11) — not touching lemond. (4) Extend tests/a11y.spec.ts with A167+ axe/role/keyboard coverage and keep the full suite green. Will open a PR into kpoin/ui-testing and @-tag @fl0rianr for review (Lovell pre-reviews).

[kpoineal]

Progress (Mattingly, Squad): PR up → #2433 (base: kpoin/ui-testing).

What I did

• Backend view: removed the preset rail, the visual preset picker, and the model-like cell-selection affordance (cell__select-btn) + all rail-only state. A backend now has NO preset by default. If a preset IS assigned, the cell shows its name+icon read-only only ([data-cell-preset]) — no assignment happens there.
• Global Presets view: added an 'Apply to a backend' control in the slideover mirroring the model flow — accessible select (aria-label + aria-describedby → global note), an 'Assign globally' button, a role=status polite success region, and a new 'Applied to backends' zone with a qualified Detach. Copy makes the semantics explicit: 'This preset applies globally to all models using this backend' and that backend presets are optional runtime defaults that MERGE with (don't replace) model presets.
• Backend-preset binding stays client-local (localStorage, invariant Request to you for benchmark report #11). lemond untouched.

a11y tests: removed obsolete A51–A54/A58 (tested removed features); added A167–A173 (rail/picker removal, axe WCAG 2.1 AA scan, accessible backend-assignment control + global copy, keyboard operability + role=status announcement, read-only display).

Tests: full suite green — 183 passed, 7 skipped.

Challenges: the always-on backend success live region initially collided with the existing model '.preset-success' selector in features test 13; resolved by giving the backend status its own class (.preset-backend-success) and renaming the button to 'Assign globally' so it doesn't collide with the model 'Apply' button locator.

@fl0rianr — ready for your review (Lovell pre-reviews). One thing to flag: backend options are derived client-side from /system-info; the merge precedence itself is unchanged and owned by main's argument-merging behavior — this PR is the UI affordance + copy only.