Singapore UX critiques: test the keyboard path through a form task

The problem

A Singapore UX practitioner can complete a form with a mouse, but their case study has no evidence that a keyboard user can reach the same controls, understand focus or finish the task.

Pick a task with a definite end

Choose a short flow such as entering a request, correcting one value and reaching confirmation. Write the intended sequence before testing, including any menu or dialog the person must use. A collection of attractive screens cannot reveal whether focus reaches their controls. Use a working, nonproduction example with invented inputs and record the device and browser tested. Name the task, its starting state and the point where you could no longer identify the current control. Record a visible indicator separately from whether the interface still accepts an action. A control can be reachable while its location is unclear to the observer. Likewise, reaching a control does not establish that activating it completes the intended task. Keep the observed browser or exercise conditions beside the path. Keep project purpose and limitations beside this precise path observation when presenting the work in a portfolio.

Keep location, action and outcome in different fields

Use a short path record: task and starting state; current named control; visible focus indication; intended next action; observed result; and unanswered step. Mark “location not identifiable” when the evidence does not show where focus is, rather than guessing a control from its visual position. Keep assistance or a supplied annotation beside the relevant observation. If the result is unknown, the next field stays unknown. A task sequence reconstructed from memory can guide an enquiry while remaining different from a recorded observation. Use a shareable fictional example if the real interface is outside the session’s material permission.

Observe focus as well as completion

SGDS v2 guidance covers keyboard access and visible focus indicators. During your review, record the control that receives focus, whether that position is visible and what happens after activation. Note where progress stops or becomes ambiguous. Avoid helping with the mouse midway and later describing the task as keyboard-complete; that assistance changes the evidence. Keep the date and version boundary with the reference. The SGDS v2 accessibility page is dated 31 May 2024 and displays a version3 notice. Its keyboard and focus guidance provides retained design context rather than a current certification standard or a verdict on your project. Use the path record below to retain the observed focus location, visibility and activation result. Use the actual appropriate review process when a project needs a wider accessibility assessment; one keyboard example does not replace research with users or checks of other interaction paths.

• SGDS | Accessibility ↗ · Source checked 8 October 2026

Find the gap in a wholly fictional slot-selection path

All controls, states and observations in this exercise are invented. A toy screen contains “Session”, “Slot” and “Continue”. The supplied record identifies visible focus at Session, then at Slot. At the next movement it reports no visible focus indication; it contains no activation or next-screen observation. The path therefore has a location-indication gap at that point. It does not establish that Continue is absent, unreachable or broken. Keep the missing location and missing activation result as separate questions. The toy task concerns this particular selection path, not a finding about a real booking service.

Bring the failure, not a whole checklist

For a critique, show the smallest part of the flow containing the barrier and the actions immediately before it. Ask whether the issue concerns control reachability, focus visibility or a transition that loses the user's place. These require different repairs. Include the expected next step so participants can test a proposed change against the actual task. Describe the last identifiable location, the attempted next movement and the state you could actually inspect. Avoid changing “I lost the visible indication here” into “the control cannot be reached” unless the observation establishes that separate result. A reviewer may help locate the missing observation, while an annotated screenshot supplies only the state it shows. Confirm the material and exercise the real session permits before expecting individual keyboard inspection. Do not upload confidential flows or ask a public attendee to operate an account merely to demonstrate the path.

Do not confuse an annotated location with a visible indicator

Continue the fictional exercise. A facilitator supplies an annotation identifying Continue as the focused control at the ambiguous step. That clarifies the location under the supplied conditions. It does not show that the original display made the location visible to the learner, and the activation result remains absent. Record the annotation’s origin rather than adding it to the original visible-state column as if the learner had seen it. A useful critique question is now whether the permitted example makes that location perceivable, rather than whether the facilitator can name the control.

Bound a later observation to the path actually examined

In a separate later fictional example, the record explicitly shows a visible focus indicator on Continue under the stated revised screen conditions. It resolves that supplied indication question for that step. It still contains no activation result, so reaching the intended next screen remains unanswered. Keep both records instead of silently giving the first attempt the later indicator. A future permitted attempt may address activation, but its planned result is not evidence yet. The review can produce a precise next check without turning one clearer position into a verdict on every control, browser or user need.

Write a bounded portfolio result

Explain what you tested, the barrier observed and the change you would verify next. A keyboard review can identify a problem without representing every assistive technology or user experience. Label SGDS as dated v2 guidance, not a latest-version badge. Choose events offering hands-on interaction and seek appropriate user feedback before making broader claims about access. Save the original record and any later permitted observation under the same stated task conditions. Describe the difference you can locate and the steps that remain unexamined. Check recovery after an invalid submission and field meaning after entry as separate tasks. A clearer focus indicator does not answer either question automatically. Choose a real critique format that can discuss the path, and confirm preparation, input, access and any review time. A useful bounded portfolio note can remain incomplete without claiming the whole interface is accessible.