Accessibility (WCAG 2.1 AA) improvements — 5 PRs open, plus one larger change to discuss #26774
ProfessorCastillo
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Summary
I've been remediating Open WebUI for accessibility so it can be used in a university setting that must meet WCAG 2.1 AA (ADA Title II / Section 508). I've opened 5 focused, independently reviewable PRs against
dev, each mapped to a specific WCAG success criterion and manually tested (keyboard-only + macOS VoiceOver + contrast math). They relate to the existing accessibility issue #2790.Wanted to (a) put them on the community's radar, and (b) open a discussion about one further change that's more invasive before I submit it, per the contributor guidelines.
Open PRs
outline-hidden, leaving no visible focus) — restored via an inset:focus-visibleringmain/navigationlandmarks (no way to bypass the sidebar; no landmark structure)ConfirmDialogexposed withrole="dialog"/aria-modaland its text input labeledtext-gray-300/400/500) failing 4.5:1 on white in light theme — remapped underhtml.lightonly (dark theme already passes, so tokens aren't changed globally)Each is scoped to be reviewable on its own; they don't depend on each other. New UI strings were generated with
npm run i18n:parse.The change I'd like feedback on before submitting
There's a sixth piece I've been holding back because it touches shared, core components and changes their keyboard behavior — the kind of thing the contributor guidelines rightly say to discuss first:
Keyboard focus management for portaled menus and the settings dialog (WCAG 2.1.1 Keyboard, 2.4.3 Focus Order):
Dropdown.svelte— because the menu content is portaled to<body>, keyboard users currently can't reach it: focus stays on the trigger and Tab moves to the next toolbar control instead of into the open menu (affects the regenerate menu, the "+" attach menu, the code-interpreter menu, etc.). The change moves focus into the menu on open, traps Tab/Shift+Tab within it, adds Arrow-key navigation, and returns focus to the trigger on Escape/close.SettingsModal.svelte— the settings tab list keeps all tabs in the tab sequence with no roving tabindex, so keyboard users get stuck cycling tabs and can't Tab into the panel to reach the actual settings controls. The change implements the standard ARIA tabs pattern (roving tabindex + arrow-key tab navigation + arole="tabpanel").Both are working and tested in my deployment, but they're more opinionated than the 5 PRs above and interact with the existing portal/modal logic, so I didn't want to drop them cold.
Questions for maintainers:
Happy to adjust any of the open PRs as well. Thanks for a great project — glad to help make it accessible to more users.
All reactions