Generative UI Needs a Contract

W3C connects generative UI, WebSkill and quality

The W3C recap published September 28 summarizes a September 6 seminar hosted by its Shenzhen Representative Office. Speakers from W3C, Beihang University, Tencent, Huawei and Baidu discussed agent interoperability, generative interfaces, accessibility, privacy, security, testing, and the relationship with existing web technologies.

Three details matter for product teams. One presentation described WebSkill as a browser-based declarative contract. Another showed a staged route from a constrained interface description to directly rendered HTML inside a harness. A third split generative UI quality into visual and source-code layers, with display correctness, requirement satisfaction, functional consistency, end-to-end success, timeliness, and aesthetics among the proposed measures.

The news is the publication of this official synthesis, not the September event itself. It does not turn every presentation into W3C consensus.

The recap did not launch a WebSkill standard

W3C describes WebSkill as a proposal that participants want to continue discussing through TPAC, Community Groups, and other activities. The earlier July 14 Web & AI meeting minutes record open questions about discovery, context size, origin scope, latency, and how WebSkill might relate to WebMCP. That is incubation, not general availability.

WebMCP is further along but still moving. Its Draft Community Group Report defines browser APIs for websites to expose tools to agents. Chrome's implementation guide calls WebMCP a proposed standard, places it behind an origin trial or local flag, and says the API remains subject to change.

A buyer should therefore reject two inflated claims: that W3C has standardized WebSkill, and that agent-ready websites now have one settled implementation path. A sensible pilot can explore the concepts without making a platform roadmap depend on their final shape.

Generative UI needs a contract, not free-form HTML

The practical pattern across the seminar is constraint. Baidu's presentation began with Markdown extensions and a UIJSON protocol for stable output, then described direct HTML rendering within a constrained, verifiable harness. The point was to reuse protocols and expert assets instead of trusting the model alone.

Consider a travel-change assistant. The model can select from approved itinerary, fare, warning, and confirmation components. It can propose a new flight, but the application owns price calculation, passenger identity, payment, and final confirmation. The generated arrangement may change; the business rules and side-effect boundary do not.

The human interface is not obsolete

The recap includes a blunt counterweight to agent hype: natural language can be ambiguous, slow, or excessive for frequent simple tasks. One speaker argued that generative UI can address some limits of text interaction but cannot replace thoughtfully designed graphical interfaces. A date picker remains better than negotiating "next Thursday afternoon, actually after four" through five turns.

Chrome's WebMCP guidance makes a similar practical choice. It supports structured tools around human-first interfaces and describes the current API as primarily suited to local browser workflows with a human in the loop. Its limitations include complex interface state and the need to visit a site before discovering its tools.

Seuil's reading is that teams should design one product surface serving both people and agents where possible. Keep accessible labels, predictable controls, clear state, confirmations, and error messages. Add machine-callable capabilities as progressive enhancement, not as a secret second product whose behavior users cannot inspect.

Quality must cover the screen and the task

A generated interface can look correct while doing the wrong thing. It can also produce valid code that becomes unusable with keyboard navigation, long translated text, a slow network, or a partial tool failure. The seminar's proposed separation of visual and source layers is useful, but teams also need the business result and the recovery path.

Test a generated expense form with a receipt missing its currency. Check whether the layout overflows, labels remain programmatically associated, the total is sourced correctly, the submit action stays blocked, and the user sees how to fix the missing value. A screenshot score alone misses four of those five failures.

This is where AI UX design meets evaluation. Track component validity, accessibility, requirement coverage, tool-call correctness, end-to-end completion, correction effort, latency, and recovery. Preserve the generated contract and action trace so a failed run can be reproduced.

What product teams can test now

Pick one bounded, reversible workflow. A useful candidate might assemble a project status view from approved data and let the user open each source. Avoid a first pilot that purchases, publishes, deletes, or changes permissions. Those actions drag identity, authorization, consent, audit, and recovery into the experiment before the interface question is answered.

Define a small component vocabulary, a typed action schema, validation rules, and one stable non-generated fallback. Test ordinary requests, ambiguous language, missing data, hostile content, unavailable tools, narrow screens, keyboard use, and interrupted runs. Compare the generated route with the existing workflow rather than with a conference demo.

The serious limitation is maturity. Browser support, APIs, permission models, accessibility behavior, and proposal names can change. Build the pilot behind an adapter and keep business rules outside the model output.

Generative UI pilot checklist

• State which claims come from the W3C recap and which are your own product hypotheses.
• Choose one reversible user task with a measurable current baseline.
• Constrain components, data, actions, permissions, and business rules.
• Keep a stable accessible interface and a manual recovery path.
• Validate visual output, semantics, function, task result, latency, and recovery.
• Log the contract, tool calls, approvals, errors, and final state for each run.
• Treat WebSkill and WebMCP as evolving inputs, not settled procurement requirements.

If a generated interface could remove real friction in one workflow, prototype the contract before changing the platform. Seuil can frame the component vocabulary, evaluation plan, human controls, and fallback as one focused AI product slice.