When you share a dialog in a public SaaS demo, show how a keyboard user gets into it, does the work, and gets back out. Start with a named button. Show where focus goes when the dialog opens, then test what happens after both cancel and success. If success removes the original button, choose a sensible place for focus to land in the updated screen and explain why.
This gives founder peers something they can reproduce. A polished recording of a pointer clicking through the happy path can help people understand what a feature does. The keyboard version answers a different question. Can someone reach the next useful action once the screen changes?
Pick a task with a clear finish
Consider a fictional SaaS app for reviewing draft contracts. A project owner can invite a reviewer from the Reviewers page. On a project with no reviewers, an empty-state card contains an “Invite reviewer” button. After a successful invitation, the app replaces that card with a list of pending reviewers. That replacement is the interesting part of the demo. The button that opened the dialog might be gone by the time the dialog closes.
Use sample accounts and addresses in your recording. Set up an empty project for the first run and a project with an existing reviewer for the second. Those two starting conditions matter because the page may use a different button, or put it in a different place, once a reviewer already exists. If you only test the second state, you'll miss what happens the first time an owner uses the feature.
Describe the task in the public post in one sentence. “Invite a reviewer to an empty project using only the keyboard” gives peers a starting point and a finish. It also rules out plenty of interesting side trips. You can test sorting reviewers or withdrawing an invitation later.
Show where focus enters the dialog
Begin the recording with visible keyboard focus on the button, then press Enter. Leave a beat after the modal opens so people can see which element gets focus. In this example, the dialog has a short heading, one email field, a role selector and the two actions. The email field is a reasonable starting point when inviting someone. If a future version adds an important explanation or warning before the field, revisit that choice so the explanation can be read in context.
Run forward and backward through the controls. Call out the control names in your captions or write them under the recording. If the role selector behaves like a composite widget, test the keys that actually operate that widget and explain the difference between moving into the selector and moving among its choices. Show the focus indicator in the video and keep the frame wide enough for a viewer to see the relationship between the active control and the rest of the dialog.
The W3C explanation of focus order describes a meaningful, operable sequence and includes a modal example. Use it to check whether each move makes sense for the task. A short dialog with a single column will often be straightforward. A two-column version with an explanation beside the fields deserves another pass. The order that works for a designer looking at the screen may be hard to follow a control at a time.
Record cancel and success as separate runs
On the first run, enter a sample address, move to Cancel and activate it. After the dialog closes, show where the next Tab goes. Returning focus to the original button makes sense here. The owner is still on the empty screen, and the button is still available if they closed the dialog by mistake.
On the second run, submit the invitation. Before you celebrate the toast, stop and look at the page. The original empty-state button has disappeared. If the keyboard lands at the top of the page, the owner may have to tab through the navigation again to find out whether anything changed. If it lands on an unrelated button in a new toolbar, the next keystroke could take the owner away from the work.
Choose a return destination that fits the next task. In this example, the updated Reviewers heading can work if it introduces the list and the pending invitation sits just below it. A nearby control for the newly added row could make sense if reviewing that invitation is the next normal step. Write down the choice, then verify that focus arrives after the list is available. Test where the next Tab goes, too. A plausible landing point can still leave the next move confusing.
W3C's modal dialog pattern covers returning focus to the invoking element and cases where a different destination makes sense. Use that guidance to describe the handoff. Keep the observed behavior tied to the build you show.
Give reviewers a trace they can compare
Write the observed sequence in the caption or article. A compact trace for the fictional success run could read like this: Empty project → Invite reviewer → Email → Role → Send invite → Reviewers heading → first available reviewer action. Include the keys used where they matter. If the list arrives after a delay, mention what was visible and where focus remained while the save was pending. Avoid editing the recording so closely that you cut out the wait.
Add an error run if it helps explain the choice. Try a malformed sample email and check that the error can be discovered and the address corrected from the keyboard. If the request fails after submission, check where focus goes and whether the typed value remains. A server rejection and a validation error can leave the interface in different states. Pick the one your audience needs to understand and say which branch you recorded.
When you share the work in a founder community such as Buildside, invite a specific response. Ask where people expected to land after success, what they saw instead, and what happened on the next Tab. If someone finds a mismatch in a public demo, ask them to describe the starting state and browser before you try to reproduce it. That gives you something concrete to follow up on even when the comment comes from someone with a different setup.
Say what the recording covers
A video shows one route through one version. Name the environment you actually used, the starting state and which branches you ran. If you used keyboard input on a laptop, keep the result scoped to that check. A recording of the visible focus ring leaves other questions open, including what a screen reader announces and how the same flow behaves with zoom. The W3C first review guide puts keyboard access and visual focus among several initial accessibility checks.
If you discover a broken return path, you can share the finding as a work-in-progress update. Give the expected landing point and what happened. Keep the public demo invitation narrow enough that other people can help without entering a real client address. When you post the fix, link back to the original example and show the repaired branch with the same starting conditions. A reader following the old recording should be able to find the current behavior.
The next time you review a public demo, watch the two seconds after the dialog closes. In an empty project those seconds can expose a decision the happy path hides. Write the intended landing point into the demo script before recording, then let the keyboard trace show whether the product follows it.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
Top comments (0)