Identify the control and its expected state
Issue #18108, opened 26 October 2026, reports web controls rendered as div, span or li elements with click handlers but without explicit focus and keyboard-activation properties. It identifies Chrome 156 and current master source; it does not specify a released server/client build or establish the problem on every browser or public deployment. [S1]
Check the relevant path instead of treating all keyboard problems as one failure:
| Visible control or symptom | What to check |
|---|---|
| Lobby Admit all, or Admit/Reject in its participant drawer | Confirm an authorized moderator and the required waiting-participant state. Test the displayed control, not an action the role should never have. [S1][S2] |
| Visitors Admit all, Go live or collapsible Visitors heading | Confirm the visitors feature and its current queue/list state. Those controls are conditional. [S1][S2] |
| Breakout room rename pencil | Test the eligible room action and its accessible name. This web rename control is different from the native room-list accordion. [S1][S2] |
| Google/Microsoft sign-in, calendar Allow access/Refresh, or View all numbers | Test whether focus reaches and activates the control separately from any later account, permission or dial-in failure. [S1][S3] |
| Chat message actions, edit cancellation or poll inputs | Use the separate chat and poll keyboard guide; its reports concern other components |
For room roles and admission rules, see login and moderator help and the visitors/lobby guide. A missing action can be correct for the role or meeting state. A visible, eligible action skipped by Tab needs a different investigation.
Make a small keyboard-only reproduction
- Record the exact client/server version, browser, OS and any screen reader. For self-hosting, use version inspection; do not equate current upstream master with the installed release.
- Use a disposable meeting with consenting test participants and an authorized moderator. Create the state needed for the control. For lobby Admit all, the reviewed component displays it when more than one participant is waiting. [S2]
- Navigate with Tab and Shift+Tab without using a pointer. Record where focus moves, whether a visible indicator exists and whether the relevant action is announced with a useful name and role.
- For a reachable action, test Enter and Space separately, choosing an action you are authorized and prepared to perform. Admission or rejection changes the meeting; test only with the disposable participants. Record whether the intended action happens once and whether focus remains usable.
- For an expandable list heading, compare its announced state before and after activation with the visible list. For sign-in or calendar controls, distinguish activation from the subsequent authentication or consent flow; never grant extra account access merely to test keyboard focus.
These are diagnostic instructions, not results from a completed meeting or assistive-technology test. A pointer making a control work can help localize the problem, but it is not an equivalent solution for someone who cannot use a pointer.
What the pinned source confirms
At Meet commit 189dc91660395cc941c3345e42daa91c0aee9de6, the reviewed lobby links/drawer items and visitor controls have click handlers without explicit tabIndex, activation-key handlers and button roles on those elements. The Visitors list header changes a visual arrow when collapsed but lacks an explicit expanded-state attribute on that header. The breakout rename icon uses another click-driven element. These source paths support the reported investigation; they are not a browser compatibility test. [S2]
The reviewed Google/Microsoft sign-in wrappers, relevant calendar controls and View all numbers text also use click-driven elements. This does not diagnose an OAuth credential, calendar service or telephone-network failure. Test focus/activation separately from the downstream action. [S3]
PR #18112 proposes keyboard handlers, focusability and semantic properties across these areas, including expanded state for the Visitors heading and a label for rename. It was open and unmerged on 26 October 2026. No released fix, supported-version matrix or independently verified result follows from the proposal. Avoid copying a proposed diff into a live meeting bundle as a generic repair. [S4]
Keep access and the meeting usable
An organizer should arrange an accessible way to perform essential actions with an authorized moderator. Evaluate any alternate control or client on the actual setup before relying on it. Keep the lobby, authentication and intended room permissions in place; removing access controls does not repair keyboard handling.
Docker and Debian/Ubuntu operators need to identify the web client actually served by the deployment. The cited report does not document a Docker environment flag, Prosody option or firewall change that adds keyboard semantics to these elements. Track upstream release inclusion, use the normal reviewed upgrade process and verify the deployed result before claiming a correction. [S1][S2][S3][S4]
For native room headers announced without expanded/collapsed state, use the separate mobile breakout check. The source, interaction model and acceptance test are different.
Verify a candidate correction
Repeat the same eligible control path with keyboard-only navigation on the candidate build. Check focus visibility, useful names and roles, Enter/Space activation, expandable state and focus after the action. Test an ineligible role or state too: improving keyboard access must not expose an action to someone who lacks permission.
Recheck pointer/touch behavior and the supported browser and assistive-technology combinations you intend to offer. A merged patch needs a matching release and deployment check. This guide’s review did not run a Jitsi meeting, browser matrix, screen reader, native device or corrected client build. Revisit the report and proposal when their status changes.
Sources
- [S1] Web keyboard-control report #18108, opened 26 October 2026, open with no comments at initial review. Its list of symptoms is a report, not independent testing by this site.
- [S2] Pinned Meet source, reviewed 26 October: lobby controls, visitor actions, collapsible visitors list and breakout rename.
- [S3] Same pinned source: Google sign-in, Microsoft sign-in, calendar controls and dial-in dialog.
- [S4] Proposed web-control correction #18112, opened 26 October 2026, open and unmerged at review; no released-build test established.