Google’s October 29 A2UI and CopilotKit guide shows agents composing interfaces from an application’s component catalog and updating them as users act. That opens a useful product question: when a generated form changes, can a keyboard user keep their place? A screen can render valid data and still send someone back to the beginning halfway through a task.
Disclosure: This article was generated and fact-checked with AI using the public sources linked here. It was published through an automated workflow and has not been reviewed by Keith.
A2UI describes interface intent as data. In the guide’s declarative approach, the application renders components it already knows, while streamed messages and user actions support multi-step interaction. That gives frontend developers a valuable place to enforce consistent behavior: the components and renderer they control. It does not, by itself, demonstrate that a particular application is usable with a keyboard.
The Garden platform case study provides a practical setting. Its staff workflows include follow-up ownership, due dates, and states, alongside people search and work management. The Planning Center replacement remains staged, with migration and staff acceptance still part of the work.
Consider a proposed generative form for assigning a follow-up task using synthetic data. The operator chooses an owner, enters a due date, and saves. This is an illustrative extension, not a description of Garden using A2UI or a report of an accessibility defect in the existing platform. The test is whether an ordinary staff task remains operable while the interface updates.
Treat the component catalog as an interaction contract
A catalog entry should define more than the fields a model may supply. For each interactive component, document how a person reaches it, how its state is conveyed, and what happens to focus when it changes or disappears.
The W3C ARIA Authoring Practices keyboard guide emphasizes visible, persistent, predictable focus. It also explains that ARIA does not supply keyboard behavior for custom widgets. Removing the focused element without a deliberate focus destination can leave focus on the document body, making the user lose their place.
For the proposed task form, prefer familiar native controls where they meet the need. A custom owner picker still needs appropriate keyboard behavior; adding a role or drawing a selection highlight is not enough. The highlighted owner and the control holding keyboard focus are different pieces of state.
Now imagine the agent adds an explanatory paragraph after the owner field. If the field still exists and serves the same purpose, that background update should not steal focus from someone entering the due date. The renderer should preserve the active control through the update where possible.
If a step genuinely replaces the form, define the next focus destination deliberately. A new step heading or its first relevant control may be appropriate, depending on the interaction. The important point is that the application owns that decision. It should not depend on whichever node happens to survive a generated layout.
Stable component identity can help a renderer preserve elements, but an identifier is not proof of correct behavior. Google’s guide describes re-emitting a flow against the same surfaceId. A stable surface reference and a stable keyboard experience are separate things to verify.
Rehearse an update while someone is in the form
Start the synthetic task with the mouse out of use. Navigate to the owner control, make a selection using its documented keys, and move into the due-date field. Confirm that the focus indicator is visible and that the control’s name and current value are understandable.
While focus remains there, deliver a controlled interface update: add help text, refresh available choices, or replace the current step. Use a recorded update sequence so failures can be reproduced. A live model’s changing output would otherwise make it harder to isolate a renderer problem.
After each update, check where focus actually landed and what the next Tab or Shift+Tab does. Continue to Save, trigger a validation error with an incomplete synthetic date, and verify that the user can find the problem and correct it. Then complete the task and inspect its saved result. These are proposed acceptance checks, not reported Garden test results.
There is a tradeoff in when to apply generated changes. Rendering every small update immediately can make the interface responsive, but unnecessary rearrangement can interrupt navigation. Holding a nonessential update until the person finishes the current field may be calmer. Keep that policy explicit and avoid hiding important errors or blocking a necessary next step.
Repeat the interaction with a screen reader on the browser and operating system the team supports. Keyboard testing and screen-reader testing answer related questions, but neither should be treated as a complete accessibility assessment on its own. Record the tested configuration and any remaining limitations.
For staff software, the consequence is concrete: an operator should not need a mouse rescue every time an assistant improves the screen. Generative UI makes it easier to compose an interface for a request. A dependable renderer lets the person finish the request after that interface starts changing.
Top comments (0)