Eldercare Robot Web Forms: Make Input Errors Understandable and Recoverable

An older person using an eldercare robot's web interface may fill in a service request and encounter a red outline or a generic “invalid input” message. If the page does not explain which field needs attention and how to correct it, the person may abandon a task even though the service itself is available. This guide looks at web form error messages in procurement and testing; age alone does not determine a person's abilities, and a good test includes people with different needs and experience.

Start with a real task and a recoverable mistake

Choose a representative web task, such as requesting an appointment through a robot's companion interface. In a test environment, intentionally leave a required field empty or enter a value in the wrong format. Observe whether the user can tell that submission failed, identify the relevant field and understand what to do next. Record the task, device, browser and assistive technology used, so another tester can reproduce the result.

The W3C explanation of error identification says that automatically detected input errors should identify the affected item and describe the error in text. This is a web accessibility criterion; passing one check does not establish that the physical robot, the service workflow or the entire website is accessible.

Describe the problem, not just the colour

A red border can be useful as an additional visual cue, but it may be missed or misunderstood. A message such as “Enter the appointment date in the format shown” is more useful than a colour change alone, provided that the requested format is actually explained and appropriate for the field. The error should make clear which input is affected and should not suggest that the whole request has been completed.

Where there are several errors, check whether the page exposes them in a way the user can find and correct. Consider how the message appears when text is enlarged and how it is announced by the screen reader used in the test. Browser-provided messages can vary by platform, so a team should test the supported combinations rather than assume that one screenshot represents every user.

Give a useful correction path

W3C's error suggestion guidance discusses providing correction suggestions when known, subject to its stated exception for security or the purpose of the content. A form might show the expected date format, explain an allowed range or identify a missing required choice. A vague request to “try again” gives the person little information about what needs to change.

Do not include sensitive details in an error message where doing so would create an information-security problem. The service owner and accessibility team should review the specific content and context. If the system cannot determine a useful suggestion, record that limitation and provide a way to get assistance where appropriate.

Check what happens to the person's work

After an error, inspect whether previously entered information remains available and whether the user can return to the affected field. Losing an entire form may require the person to repeat a long task. At the same time, saving personal or health-related information has privacy and security implications. The product team should define which information is retained, for how long and who can access it, rather than keeping everything indefinitely.

For a hypothetical test, a person enters a contact method and appointment date but forgets a required service choice. The page identifies that choice in text, keeps the earlier entries and allows the person to correct the mistake. The tester then checks that the request is submitted only once and that the confirmation accurately describes the result. This is an illustrative scenario, not a claim about any particular robot.

Consider also what the service team sees after the person corrects the form. An unsent request and a successfully submitted request should not be presented as the same status. If the connection fails at the moment of submission, the interface should communicate what is known and offer a clear way to check the outcome rather than inviting repeated submissions without explanation. The exact behavior depends on the service and its technical design; procurement staff can ask the supplier to demonstrate it in a controlled test.

Include people and support staff in evaluation

Ask participants to complete the task at their own pace, without coaching them through the error unless help is part of the scenario. Note where they hesitate, what they believe happened and whether they can recover. Do not treat the participant as the source of failure. Review findings with designers, developers, service staff and, when appropriate, the people who will actually use the interface.