The Demo Looked Great. Then Someone Tried to Use It With a Keyboard

Every software demo has a certain show-home quality. The cursor glides, the notifications arrive at exactly the right moment, and nobody asks the awkward question: what happens when the person using this cannot see the screen, hear the call, or reach for a mouse?

For UK teams in 2026, that question matters more than ever. Collaboration tools are where work happens — meetings, documents, decisions, the lot. If the tool is hard to use for disabled colleagues, it is not just a technical wrinkle. It is a productivity problem, a retention problem and, frankly, a manners problem. Yet accessibility often sits at the bottom of the procurement spreadsheet, somewhere below single sign-on and whether the pricing page has a hidden asterisk.

The show home problem

A vendor demo is designed to show the best version of a product. It is not designed to show what happens when live captions lag behind a fast-talking Scot, or when a screen reader announces a button as “unlabelled button” for the fifth time. Those things tend to surface after the contract is signed, when a new starter joins and quietly cannot use the tool everyone else has already made peace with.

The frustrating part is that accessibility is not mysterious. It is a set of practical checks. The trick is doing them before the rollout, not after the complaints have been filed under “difficult colleague”.

Where collaboration tools usually stumble

A few familiar trouble spots come up again and again.

Live captions and transcripts. Automatic captioning has improved, but it still struggles with accents, jargon and the particular chaos of a team call where three people talk over each other. If captions are unreliable, the meeting is unreliable for anyone who depends on them.

Screen-reader support. A tool can look clean and still be a nightmare to navigate with a screen reader. Buttons need proper labels, headings need structure, and dialogs need to be announced clearly. “It works with NVDA” is not the same as “it works well”.

Keyboard-only navigation. Try using the tool for fifteen minutes without a mouse. Can you reach the share button? Can you move between messages? Can you tell where you are on the screen? If not, keyboard users are locked out of the everyday flow.

Colour contrast and visual clarity. Light grey text on white might look tasteful in a brand deck. In a busy channel, it can be unreadable. The same goes for status indicators that rely on colour alone.

Documents and exports. Teams often check the app and forget the files it produces. A screen-reader-friendly interface is little comfort if every exported report is a PDF built like a maze.

Questions to put to the vendor

You do not need to become an accessibility expert to ask better questions. You just need to be specific. Try these before the next renewal or rollout:

• Can you show live captions working on a real call, with several speakers and background noise?
• Which accessibility standards does the product aim to meet, and where can we see the latest audit?
• How does keyboard navigation work in the main workflows — messaging, meetings, file sharing and settings?
• What are the known accessibility gaps, and what is on the roadmap to fix them?
• Can users adjust text size, contrast and motion without breaking the layout?
• How are third-party integrations tested for accessibility?
• What support do you offer if a team member hits a barrier during onboarding?
• Can we run a small pilot with disabled colleagues before a wider rollout?

That last one is the most useful. A pilot with real people doing real work will tell you more than any polished demo ever could.

Small fixes you can make now

You do not have to wait for a full procurement review to improve things. Start with the tools you already have.

Run a “no-mouse Friday” test on your main collaboration platform. Ask a couple of team members to spend an hour using only the keyboard and note where they get stuck. Turn on captions by default in meetings, but check them against a recording before trusting them. Create document templates that use proper heading styles rather than bold text pretending to be a heading. And build a short accessibility note into your team handbook: who to ask, what to check, and how to flag a problem without it becoming a whole thing.

It also helps to make accessibility a normal part of tool reviews, not a separate project. Add three questions to your existing checklist. Ask the vendor for their latest audit. Include a disabled colleague in the pilot group. None of that is dramatic, and that is the point. It should be as routine as checking whether the tool works on a phone.

Don’t wait for the complaint

Accessibility is often treated as a compliance box, something to sort out when someone raises it. That is a bit like buying a team van and only checking whether the doors open after the first passenger gets stuck outside.

A small, practical audit before a rollout is not about gold-plating the process. It is about making sure the tool you are paying for actually works for the people who have to use it. In a UK team, that is not a niche concern. It is the whole point.

So before the next demo, add one more question to the list: can everyone on the team actually join in? If the answer is “we assume so”, that is your first fix.