When you build in public, share a keyboard walkthrough of one product task with its starting conditions, visible focus path and observed result. Explain exactly what you checked and what you did not. A short walkthrough can expose a concrete obstacle and invite useful review without claiming that the whole product has passed an accessibility audit.
This is a different kind of build update from a polished feature tour. The useful artifact is a record someone else can follow. The public reader needs to know how you moved through the task, where the result changed and whether the explanation comes from an actual check or a hypothetical example.
Pick a task with an observable finish
Consider a fictional appointment tool. The task is to filter available sessions to one tutor and choose an open time. The start is the availability page with a known set of invented sessions. The finish is the selected session’s details, before any real booking is submitted. This gives the walkthrough a clear boundary.
A tour of every interactive element on the site would be a different project. Start with the task your build update is about. If you are discussing a new filter, the reader should be able to see how the filter relates to the choice that follows. Do not make the public example depend on private customer information.
Write the expected result in ordinary language before checking. In this fictional case, the chosen tutor’s sessions should be available to inspect, and the person should be able to move onward from the filter. That expectation is specific enough to compare with a recorded observation. “Everything should be accessible” is too broad for this single note.
Learn the relevant keyboard checks
The DWP Accessibility Manual’s keyboard-testing guide describes checks for operating controls, logical focus order, visible focus and getting out of interactive areas. It also explains that keys can vary with the browser. Use the guide to understand the check before recording a public demonstration; a checklist alone is not a result.
For this walkthrough, focus means the element currently receiving keyboard input. You need to be able to identify that element as you move. If you cannot see where input will go, note the uncertainty rather than using the mouse to rescue the recording and presenting the sequence as keyboard-only.
Keep the browser and operating-system context in your private check note and in the public report when relevant. If a setting changes how the task behaves, record it. The point is to make the observation inspectable, not to imply that every visitor’s keyboard configuration will produce an identical sequence.
Keep the starting conditions reproducible
Use a test page or account you are authorized to use and create invented appointments. Record the product version or date, the page state and any setup needed to reach it. You do not need to publish an account identifier or access credential. Explain the state without exposing the private route used to prepare it.
Begin with a fresh pass through the task so you do not accidentally rely on focus or a filter value left over from a previous attempt. If the product remembers a selection, include that behavior in the conditions or deliberately reset it using the normal interface. A reader cannot reproduce a starting state that your report leaves unstated.
The fictional example could use three sample sessions with clearly different tutors and times. These are test fixtures, not customer bookings or evidence of demand. Say that the data is invented. A small, recognizable set makes it easier to tell whether the filter actually changes the available choices during the walkthrough.
Record actions and observations separately
Keep a short sequence with two kinds of information: the action you took and what you could observe afterward. For example, the hypothetical note might say that focus reached the tutor filter, a tutor was selected and the displayed session list changed. The next observation might concern where focus went when the person continued.
Do not infer the underlying implementation from that sequence alone. A visible pause does not establish a network problem, and an unexpected focus position does not identify the exact code responsible. Your public note can name the symptom and the conditions while leaving the cause for investigation.
If you discover an obstacle, preserve the useful part of the record. “I could not identify the focused control after applying the filter” is a specific observation. “Keyboard navigation is broken everywhere” is a broader conclusion. If you used the mouse after that point, label where the keyboard-only attempt ended instead of editing the interruption out.
Make the recording explain the task
A useful video should let a viewer follow the state changes without guessing which key was pressed. You can add a simple action caption or narrate the relevant step, then supply a text account beside the recording. Keep captions accurate and explain any cuts. An edited demonstration is not the same artifact as an uninterrupted check.
Avoid cursor movement that implies a mouse action when you are discussing a keyboard path. Keep the important control and focus indicator readable in the frame. If the recording cannot show them clearly, use a closer view or a carefully labeled still that explains the specific state. Do not add decorative effects that obscure the evidence.
The text note should stand on its own for a reader who does not watch the clip. State the task, conditions, obstacle or result and next check. A video thumbnail with “fixed accessibility” is not enough. It hides the scope and leaves other developers unable to tell which behavior you actually examined.
Report the change at the same scope as the check
Suppose the fictional developer makes a change intended to keep the focus location clear after filtering. A follow-up should repeat the same task and conditions before describing the observed difference. It should also say whether other relevant states, such as no matching sessions, remain unchecked. A successful path is not evidence about every path.
A careful update might say that the selected-session task was completed using the keyboard in the stated setup after the change. It should not announce full accessibility compliance from that one result. A broader assessment involves more questions, users and conditions than this article’s bounded demonstration covers.
Keep the earlier obstacle and the later observation distinguishable. A reader arriving after the fix should understand what changed and why the original note exists. If the old recording remains public, add a dated follow-up or link to the current explanation rather than leaving incompatible claims without context.
Ask peers for a specific review
A public build update can invite a peer to try the same task and report where their experience differs. Explain the required setup and ask them to use only information they can safely share. Do not require a personal booking or a real customer account just to comment on your public example.
Buildside describes founders sharing progress and offering useful observations; I build Buildside. That is the community context for a request such as, “Can you follow this focus sequence, and where does the explanation become unclear?” The request is about one piece of work, not an invitation to certify the whole product.
Before publishing the note, check that its strongest claim matches the artifact. If you only planned a walkthrough, call it a plan. If you completed one, state the conditions and result. If you stopped at an obstacle, show that limit. A precise account of one keyboard task gives other builders something useful to examine and gives you a clear next check.
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)