Accessibility: fix Lighthouse findings (labels, ARIA tab roles, contrast)

[maboa]

Summary

A Lighthouse accessibility audit surfaced several issues, mostly missing form labels, misused ARIA roles on the tab/switch controls, and one contrast problem. Grouped below with proposed fixes. Automated checks are a subset — a manual screen-reader/keyboard pass is also included at the end.

1. Missing form labels (screen readers can't announce these)

Add an aria-label (or associated <label>) to each:

• File inputs: #parakeet-file-input (and the equivalents in the whisper/deepgram templates), #deepgram-json-file, #deepgram-json, #srt-file, #srt, #vtt-file, #vtt → e.g. aria-label="Choose a media file" / "Choose a JSON/SRT/VTT file".
• Select: #load-localstorage-filename (Recents "load project" dropdown) → aria-label="Load a saved project".
• Modal toggle checkbox: #captions-modal (visually-hidden .modal-toggle) → aria-label, or aria-hidden="true" since it's a CSS mechanism, not a user-facing control.

2. ARIA tab roles on incompatible elements

Failing: div.tabs.tabs-lifted (tablist missing required tab children), and role="tab" on <input>/<label> (incompatible element). Affects both the transcribe Local/Cloud switch (.service-switch, index.html:831) and the engine tabs (role="tab" on <input type="radio">, index.html:838+).

This is the DaisyUI CSS-only radio pattern colliding with ARIA tab semantics. Two options:

• (preferred, low-risk) Drop the role="tab"/"tablist"/"tabpanel" attributes and lean on the native radio-group semantics — wrap each group in role="radiogroup" (or a <fieldset><legend>) with an aria-label, keeping the per-radio aria-label. Radios are already an accessible "pick one" pattern and announce correctly.
• (heavier) Implement full ARIA tabs (real tab/tabpanel with aria-selected/aria-controls + JS focus management) — more code, and the pattern is currently CSS-only.

3. Multiple labels on one field (unscored)

#info-modal (modal-toggle) is targeted by two for="info-modal" labels — the open button (#info-btn, index.html:366) and the close ✕ (index.html:451) — which screen readers announce inconsistently. Inherent to the DaisyUI open+close modal-toggle pattern. Fix by marking the toggle aria-hidden="true" and giving the visible buttons their own accessible names (the open button already has aria-label; give the close button aria-label="Close"). Applies to the other modal toggles too.

4. Contrast

li items in #file-picker (Recents list) fail the contrast ratio. Darken the text / adjust the token so it meets 4.5:1 (also re-check in both light and dark themes).

5. Manual checks to do (Lighthouse can't automate)

Keyboard focusability of all controls; visible focus + state; logical tab order matching visual/DOM order; focus not trapped; focus moved to newly-opened modals and returned on close; landmark elements for navigation; offscreen content hidden from AT. Worth a dedicated screen-reader pass (VoiceOver/NVDA) since the app is modal- and custom-control-heavy.

Notes

• js/hyperaudio-lite.js, js/caption.js are vendored — any fixes there go upstream; the rest are editor markup (index.html) and CSS.
• Priority order: (1) labels and (4) contrast are quick, high-value wins; (2)/(3) need a small design decision on the tab/modal patterns.

Source: Chrome Lighthouse accessibility audit.