Knowing who is speaking is as fundamental as hearing what is said. Yet Microsoft Teams presents that essential meeting context visually while giving a blind screen-reader user no equivalent one-command way to retrieve it. When a conversation moves quickly, the user can miss who made a decision, asked a question, or committed to an action. It's table stakes—it's the minimum.

Teams needs to close that gap with a keyboard shortcut that announces the current speaker's name without moving focus, opening the People pane, or changing the meeting layout.

The current problem

Microsoft says that Teams meeting views highlight active speakers. A sighted participant can glance at the meeting window and identify the highlighted person. A blind participant using a screen reader cannot retrieve the same information with one command—or, in the case of MS Teams on Windows Desktop, any command at all that doesn't require AI analysis.

As of this writing, Microsoft does have a similar feature for announcing raised hands. See Microsoft's published keyboard shortcuts for Microsoft Teams showing Ctrl+Shift+L to Announce raised hands on Windows. The list does not include a corresponding command to announce the active speaker, but wouldn't that also be easy to do since Microsoft is already doing something similar?

Zoom and Google Meet already provide this command

Two other major meeting platforms demonstrate how direct the interaction can be.

Zoom

Zoom documents these shortcuts for Read active speaker name:

  • Windows: Ctrl+2
  • macOS: Command+2

The name is announced without requiring the user to find the speaker in the participant list. Zoom also lets users edit shortcuts in its keyboard shortcut settings. See Zoom's official hot keys and keyboard shortcuts documentation.

Google Meet

Google Meet documents these shortcuts for Announce who's currently speaking:

  • Windows and ChromeOS: Ctrl+Alt+S
  • macOS: Control+Command+S

Google explicitly groups this with commands that have no equivalent user-interface button and produce only screen-reader output. The same group includes commands for announcing current room information and recent reactions. See Google's instructions for using Google Meet with a screen reader.

These implementations establish a clear accessibility pattern: a participant should be able to request meeting context immediately, without navigating away from the current task.

Why active-speaker identification matters

Knowing who is speaking is fundamental meeting context. The need is especially clear in:

  • large meetings;
  • meetings with unfamiliar participants;
  • cross-company meetings;
  • conversations involving people with similar voices;
  • fast discussions in which people interrupt or hand the conversation to one another; and
  • meetings in which a blind participant is simultaneously using chat, notes, shared content, captions, or another Teams control.

Teams already tracks the active speaker for its visual meeting views. Exposing that state on request would reduce unnecessary navigation and let a screen-reader user remain engaged with the conversation and the task at hand.

Recommended Teams improvement

Teams should add a command named Announce active speaker (screen reader). When invoked, it should expose the display name of the participant Teams currently considers the active speaker through the appropriate accessibility API.

The command should not:

  • move keyboard focus;
  • open the People pane;
  • change the meeting layout;
  • move to the active participant's video tile;
  • interrupt work in chat, captions, shared content, or another meeting pane; or
  • use a separate Teams-generated voice when a screen reader is running.

The user's screen reader—such as JAWS, Narrator, or NVDA—should announce the result.

For the MS Product team, here's a User story

For the Microsoft team, you can copy/paste this right into your SSDLC tooling.

As a blind or low-vision Microsoft Teams organizer or participant who uses a screen reader, I need a keyboard command that announces the name of the participant who is currently speaking, so I can obtain the same speaker-identification information that Teams presents visually without moving focus, navigating through the participant list, or interrupting what I am doing in the meeting.

Acceptance criteria

  1. The active speaker can be queried. While participating in a Teams meeting, pressing the assigned shortcut announces the display name of the participant Teams currently identifies as speaking.
  2. The screen reader provides the announcement. Teams exposes the result through the appropriate accessibility API so that JAWS, Narrator, NVDA, or another supported screen reader announces it. The feature does not depend on Teams generating separate text-to-speech audio.
  3. Keyboard focus does not move. Focus remains on the element that was active before the command was invoked.
  4. No interface navigation is required. The People pane does not open, the layout does not change, and focus does not move to a video tile.
  5. The command works throughout the meeting interface. It works from meeting controls, meeting chat, captions or transcript content, shared-content controls, and other meeting panes.
  6. Speaker changes are reflected promptly. If Teams changes its active-speaker state from Participant A to Participant B, the next query announces Participant B.
  7. The command reports the current state on request. A user can invoke it whenever needed instead of receiving an automatic announcement every time the speaker changes.
  8. Silence is handled clearly. If Teams cannot identify an active speaker, the screen reader receives concise feedback such as “No active speaker.” The command never fails silently.
  9. The announced identity is consistent. The name matches the participant's display name elsewhere in the Teams meeting.
  10. The default shortcut does not conflict. The selected combination avoids existing Teams and Windows commands and commonly used assistive-technology shortcuts.
  11. The command is discoverable. It appears in the Keyboard shortcuts window with a clear name such as Announce active speaker (screen reader).
  12. Captions are not required. The command works when live captions and transcription are turned off.
  13. The People pane is not required. The command works while that pane is closed and does not open it.

How to test the proposed command with JAWS

This test plan is for validating a future implementation. It does not describe functionality currently available in Teams.

Test environment

Use:

  • Windows 11;
  • the improved Microsoft Teams desktop application;
  • the current version of JAWS;
  • at least two additional meeting participants; and
  • the shortcut Microsoft assigns to Announce active speaker.

The steps below call that command [Active Speaker Shortcut].

Test 1: Announce the active speaker

  1. Start JAWS.
  2. Join a Teams meeting with at least two other participants.
  3. Ask Participant A to speak continuously for several seconds.
  4. Press [Active Speaker Shortcut].

Expected result: JAWS announces Participant A's Teams display name.

Test 2: Report a speaker change

  1. Ask Participant A and B to have a quick back-and-forth conversation.
  2. Press [Active Speaker Shortcut] every 1–2 seconds, and confirm that JAWS announces the right participant.

Expected result: JAWS announces the right Participant alternating quickly between multiple speakers.

Test 3: Preserve keyboard focus

  1. Place focus on a recognizable Teams control, such as Mute or Unmute.
  2. Use a JAWS command to confirm the focused control.
  3. Ask another participant to speak.
  4. Press [Active Speaker Shortcut].
  5. Query the focused control again.

Expected result: JAWS announces the speaker, and focus remains on the same control.

Test 4: Work in meeting chat

  1. Open meeting chat and place focus in the message compose field.
  2. Type several characters without sending the message.
  3. Ask another participant to speak.
  4. Press [Active Speaker Shortcut], then continue typing.

Expected result: JAWS announces the participant, focus remains in the compose field, and the draft is unchanged.

Test 5: Work throughout the meeting interface

Repeat the command while focus is in each of these locations:

  • meeting controls;
  • meeting chat;
  • the People pane;
  • captions or transcript content;
  • shared-content controls;
  • the More actions menu; and
  • another interactive meeting pane.

Expected result: The command reports the same active-speaker state in every location and does not move focus.

Test 6: Keep the People pane closed

  1. Close the People pane.
  2. Ask a participant to speak.
  3. Press [Active Speaker Shortcut].

Expected result: JAWS announces the participant, and the People pane remains closed.

Test 7: Work without captions or transcription

  1. Turn off live captions and confirm that transcription is not running.
  2. Ask another participant to speak.
  3. Press [Active Speaker Shortcut].

Expected result: JAWS announces the active speaker without depending on captions or transcription.

Test 8: Report silence

  1. Ask all participants to remain silent for several seconds.
  2. Press [Active Speaker Shortcut].

Expected result: JAWS announces a concise status such as “No active speaker.”

The desired accessibility outcome

The intended experience is simple:

Someone is talking. The blind participant presses one shortcut. The screen reader announces who it is. Focus stays exactly where it was.

Zoom already provides this interaction. Google Meet already provides it. Teams already supports screen-reader-specific meeting commands and already identifies the active speaker visually. Microsoft should expose that information directly to screen-reader users as well.