A meeting you can run without a mouse.

01Captions, and what they cost in bandwidth

Captions are generated on our side and sent to the client as text, which is the cheap way to do it. The caption stream adds roughly 0.01 Mbps to a participant's downstream. That is nothing next to a 720p tile at about 1.2 Mbps each way, so turning captions on never pushes anyone over a limit, and nobody has to choose between reading the call and seeing it.

Latency sits between one and two seconds behind the speaker on a healthy connection. On a degraded link it tracks the audio rather than the video, which matters: when the picture freezes, the caption keeps going, because the caption is built from the audio stream and audio is the last thing we drop.

The caption panel is resizable, detachable to the lower third, and remembers its position per device. Text size has four steps and the largest one is about 28px at a standard viewing distance. Caption colours use the same sand-on-umber contrast as this page, measured at better than 7:1.

What captions are not: a legal record. They are generated speech recognition and they get names, acronyms and overlapping speech wrong. For anything that has to be exact, use the transcript from the recording and correct it. A transcript ships with every cloud recording, and recordings are kept for 30 days unless you change it.

02Running a call from the keyboard

Every control a host needs during a meeting is reachable by keyboard, and the focus ring is visible against the dark interface at the same two-pixel weight used on this site. We test this by unplugging the mouse, not by reading a checklist.

• Mute and unmute, camera on and off, raise hand, and the push-to-talk hold all have single-key shortcuts that work from anywhere in the meeting window.
• The participant list is a listbox with arrow-key navigation. Admitting someone from the waiting room, muting them or moving them to a breakout room is done from that list with Enter and the context menu key.
• Screen sharing opens a dialog with a real focus trap and Escape cancels it. The share picker lists windows by application name, so you can share one window instead of the whole desktop without hunting through thumbnails.
• Chat has its own region with a shortcut to jump into it and a shortcut to jump back to the video. Posting a message never steals focus from the meeting controls.
• Leaving the meeting takes two deliberate keystrokes, never one, because an accidental leave in a 300-person town hall is its own accessibility problem.

On this website the same rules apply. The sidebar collapses into a drawer below 1024px that traps focus while open, closes on Escape and returns focus to the button that opened it. Skip to content is the first thing in the tab order on every page. Tap targets are at least 44 by 44 pixels, which is also why the nav rows look taller than a typical menu.

03What a screen reader hears during a meeting

A video call is mostly silent state change, and that is the hard part. Someone joins, someone raises a hand, someone starts sharing. A sighted participant catches that in peripheral vision. A screen reader user gets it only if we announce it.

So we announce it, through one polite live region, with a rate limit. Joins and leaves are batched if more than three happen within five seconds, which stops the start of a 50-person meeting from becoming an unbroken minute of speech. Hand raises, share starts, breakout room moves and recording start and stop are always announced immediately, because each of them changes what you should do next.

The active speaker is announced on change, but only when the change is longer than two seconds. Without that threshold, a three-way conversation produces a name every second and the call becomes unusable. You can turn speaker announcements off and keep the rest.

Tested combinations, in the order we test them: NVDA with Firefox on Windows, JAWS with Chrome on Windows, VoiceOver with Safari on macOS, VoiceOver on iOS. Android TalkBack with the mobile client is tested less often, once a quarter rather than once a release, and that is a real difference worth knowing about before you standardise on Android handsets.

04This website, specifically

Text sits at a measured contrast of at least 7:1 against the umber ground, except for secondary meta lines which hold above 4.5:1. The body is set at 17px with a 1.65 line height and the measure is capped near 68 characters. Headings are a serif with high stroke contrast and are never set below 1.5rem, because that face stops being legible when it gets small.

Zoom to 200% in the browser and nothing is lost, nothing overlaps and nothing scrolls sideways. The layout is fluid from 320px upward. Tables that carry real data, such as the cookie ledger, become labelled blocks on a phone rather than a squeezed grid you have to scroll horizontally.

The deployment configurator is operable from the keyboard end to end. The host slider has a paired number input so you can type 180 instead of dragging for it, every output is announced when it changes, and the generated specification sits in a text area you can read, copy or edit before it goes into an inquiry. Nothing in it depends on hover or on dragging.

The support chat widget opens with a button, traps focus while open, closes with Escape and returns focus. It polls for new messages every five seconds and only while it is open. New messages are announced politely rather than interrupting whatever you are reading.

05The gaps we have not closed

Every accessibility statement that claims full conformance is either lying or has not been tested by anyone who depends on it. Here is what is actually broken, with what we are doing about it.

• Captions are English only. There is no Spanish caption track, which in Austin is a genuine problem and the request we get most. Work started; no date promised, because a half-working Spanish model is worse than none.
• The whiteboard canvas is not usable with a screen reader. You can join the board, you cannot read what is drawn on it. The workaround is that every board exports to an image attached to the meeting notes, and a sighted colleague can describe it in the thread. We are not going to pretend this is adequate.
• Breakout assignment by keyboard is slower. Dragging thirty people into six rooms takes a facilitator about forty seconds with a mouse and nearer three minutes from the participant list. The automatic split works from the keyboard in one keystroke, so most people use that instead.
• The transcript view on phones under 360px wide is cramped. Speaker labels wrap onto their own line and the timestamp column crowds the text. Readable, not comfortable. It is queued behind the caption work.

None of these is in the admin console, which is the part most often bought by organisations with a procurement accessibility review attached. The console's roles, audit log and retention settings are keyboard-operable and screen-reader-labelled throughout, and we will walk your reviewer through it on a call rather than sending a document.

06If something here blocks you

Write to [email protected] or call +1 (925) 555-2231. By post: Ve Bex, 167 Mill Street, Office 12, Austin, Texas 31098, United States. Tell us the page or the meeting control, the browser and the assistive technology, and what you expected to happen.

You get a reply within 7 days from someone who can reproduce the problem, not an acknowledgement from a queue. If a fix is going to take a release cycle, we say which release. If we are not going to fix it, we say that too, and we say why, and it goes on the list above.

Where a document on this site is a barrier in itself, ask and we will send the same content as plain text or read it to you on the phone. That applies to the terms of service, the privacy notice and the cookie ledger equally. To ask for a copy of your data, use the data request page.