Care Robot Portal Acceptance: Follow the Keyboard Focus

A care robot portal may be used by a resident, a family member or a member of staff arranging a service. A procurement demonstration that follows only the mouse pointer leaves another useful question open: can a keyboard user tell where the next action will occur? This care robot portal review proposes a fictional booking exercise for a supplier handover. It does not describe a study of real residents or make assumptions about how all older people use technology.

Give the demonstration a task and a stopping point

Choose an agreed task with the supplier, such as opening a demonstration booking form, choosing a service description and reaching a review screen. Use a demonstration account and invented entries so that the exercise does not create a real booking. State whether the task includes closing an optional panel, returning to an earlier field or reviewing a confirmation message. A tour of isolated buttons is less informative than following the actual sequence the buyer expects to receive.

The observation sheet should identify the supplied portal version, browser, viewport and starting page. Those details locate the review; they do not turn a single browser exercise into a finding about every supported environment. Assign one person to follow the task and another to record the visible interface changes if that arrangement suits the demonstration. Neither role should infer a resident's needs from the reviewer's own preferences.

Watch the focus indicator rather than guessing from the cursor

The W3C Understanding Focus Visible guidance explains the WCAG requirement for a visible keyboard focus indicator in a mode of operation. This concerns knowing which interface element has focus. It is a useful reference for an observation the buyer can request, not evidence that the delivered portal already meets the criterion.

At each agreed step, ask whether the reviewer can identify the focused item before activating it. Record the control's visible label and what indicated focus. If the reviewer loses track, note the point in the task and ask the supplier to explain the intended behavior. Do not substitute the position of a stationary mouse pointer for evidence about keyboard focus. Similarly, a decorative highlight on the selected service is not necessarily the indicator of the control currently receiving keyboard input.

Keep the focused control in view when panels appear

The related W3C Focus Not Obscured (Minimum) explanation concerns a component receiving keyboard focus not being entirely hidden by author-created content. Its minimum requirement should not be rewritten as a promise that every component is completely unobscured. The guidance identifies overlapping interface content as a relevant concern.

In the fictional portal, suppose a fixed summary panel remains visible while the reviewer continues through the form. Ask the supplier to show what happens when focus reaches a control near that panel. Record whether the component can be located and how the task continues. If the panel has not appeared during the demonstration, the reviewer cannot claim to have checked that condition. Request the relevant state explicitly instead of marking it complete from a clean starting screen.

Keep the indicator question separate from the overlapping-content question. A focused control could have a visible styling rule while its current location is obscured. Conversely, seeing a control somewhere on the screen does not establish that the reviewer can identify it as the current keyboard target. Recording both observations helps the supplier understand the particular gap without reducing the discussion to a vague statement that navigation feels wrong.

Write a handover finding that can be checked again

A useful finding identifies the step, interface state and observation. For example, a reviewer might record that the demonstration reached the review screen but the focused item could not be located after a particular panel opened. That is a proposed reporting pattern, not a failure found in any actual product. Ask for a response that addresses the same state, followed by an agreed repeat observation if a change is delivered.

Do not close the finding merely because a new screenshot shows an outline around a button. The repeat review should still follow the relevant task and panel condition. Retain the earlier note alongside the response so that the original question remains understandable. If the supplier explains that a state belongs to a different supported workflow, clarify the procurement scope rather than silently changing the demonstration after the fact.

The final acceptance note should say which task and conditions were observed, which focus questions remain unanswered and who will supply the next evidence. It should not announce that the whole portal is accessible or that care outcomes have improved. The drawings are original conceptual review aids. Our care robot reading collection offers related interface discussions, while the article directory provides further material for a more complete procurement review.