You ask an assistant to find somewhere for dinner. It researches restaurants and gives you three suggestions. Useful.

Now give it access to your calendar. It excludes the nights when you are busy. More useful.

Now give it the ability to make reservations. The interaction has changed.

The question is no longer only whether the system understood what you meant. The system can now create consequences.

What exactly did you authorise?

Generation is easier to reason about than action

Much of the first generation of AI product interaction has revolved around outputs.

• Generate some text.
• Summarise a document.
• Create an image.
• Suggest code.
• Answer a question.

In each case, there is a natural boundary. The system produces something. The human chooses what happens next.

Agents weaken that boundary. A system can research, navigate, modify information, invoke tools and interact with external services.

Now the answer to a prompt may not be another artefact. It may be a changed state somewhere else.

• An email sent.
• A meeting moved.
• A pull request opened.
• A file edited.
• A purchase prepared.

The central design problem therefore moves from: What can the model produce?

towards: What is the system authorised to change?

Access and authority are different things

This distinction becomes clearer in current agentic products.

ChatGPT Work's cloud browser can interact with supported websites, including clicking buttons, entering information and working inside signed-in experiences.

Its current product guidance explicitly separates permission to access a website from approval for a consequential action. Allowing access to a site does not remove the need to confirm actions that can be hard to reverse or create significant financial, legal, account or other real-world commitments, such as confirming a booking or making a payment.[1]

That distinction is more important than it first appears.

Access answers: Can the system enter this environment?

Authority answers: What may it do once it is there?

Those are completely different permissions.

This difference existed before AI, but agents make it central. A calendar application may have permission to edit events. That does not automatically answer whether an agent should reschedule a client meeting because it inferred that another time was more convenient.

Technical capability does not define legitimate delegation.

Delegation needs boundaries

When people delegate tasks to other people, they rarely delegate infinite authority.

“Find somewhere for dinner” is an objective.

“Find somewhere for dinner within twenty minutes of the hotel, under €80 per person. You can reserve it, but ask me before anything with a cancellation charge.” is something else.

It contains a small authority model.

Goal. Scope. Constraint. Threshold. Escalation condition.

AI interfaces need ways of representing the same thing. Not necessarily as a formal settings panel. But the system has to know where delegated authority stops.

I think of that boundary as the delegation contract.

The contract answers:

• What outcome is the agent pursuing?
• What resources can it use?
• What actions can it perform?
• What constraints apply?
• What requires approval?
• What should happen outside the agreed boundary?
• How can the person stop or reverse it?

If the answers are unclear to the user, the agent may be capable without being trustworthy.

GitHub makes the boundary visible through the pull request

Consider GitHub Copilot's cloud agent. GitHub documents a workflow where the agent can work autonomously on an issue or developer request and raise a draft pull request. Its default guardrails restrict the agent from merging that pull request itself and require human review before merge.[2][3]

This is not just an engineering workflow. It is an authority boundary embodied in an existing product primitive.

The agent is allowed to:

investigate, change code, prepare a proposal, respond to feedback.

But the pull request creates a checkpoint before those changes become part of the shared codebase.

The important interface element is not the AI icon. It is the boundary between prepared action and committed action.

GitHub also now exposes more explicit agent-merge workflows in some Copilot experiences. Those workflows remain bounded by repository rules, checks and approvals, which is useful precisely because it shows that “more autonomy” is not one switch. It is a set of permissions layered onto existing governance.[4]

We need more than an “autonomous / not autonomous” switch

AI products are often discussed as though autonomy is one variable. It is more useful to treat it as a gradient.

A system can observe. It can recommend. It can prepare. It can execute. It can commit.

These levels are not determined by intelligence. They are determined by product permissions and interaction design. The exact same model can occupy completely different positions depending on the tools it receives.

A travel assistant that compares flights is not the same product as one that can purchase the ticket. A coding agent that prepares a patch is not the same product as one that can deploy production code. A financial assistant that explains transactions is not the same product as one that can initiate them.

Confirmation everywhere would defeat the point

There is an obvious solution to the authority problem. Ask before every action.

• May I search?
• May I open this file?
• May I edit it?
• May I save?
• May I continue?

The system is now safe partly because it is barely delegated.

The opposite approach is complete autonomy. That works until the agent confidently makes the wrong consequential decision.

The design problem is therefore not whether people remain “in the loop” in some abstract sense. It is where the loop closes.

Approval belongs where the consequence changes.

• Reading a calendar is not the same as deleting an appointment.
• Finding flights is not the same as purchasing one.
• Editing a local branch is not the same as merging it into shared code.
• Drafting a message is not the same as sending it to 200 people.

This suggests a more practical rule:

Ask for intervention when an action crosses a meaningful consequence boundary, not merely because the agent performed another step.

Reversibility changes how much autonomy is reasonable

There is another variable: what happens when the system is wrong. Consider two agent actions.

The first reorganises a private draft. The second permanently deletes a shared customer record.

Even if the probability of error were identical, these actions should not inherit identical authority. One is cheap to reverse. The other is not.

The interface should therefore understand not only what action is happening, but also the cost of recovering from it.

This is one reason familiar product primitives such as drafts, pull requests, version history, staged changes and confirmation boundaries become newly important in agentic products. They create places where automation can do substantial work without immediately creating irreversible consequences.

The agent also needs an understandable history

As workflows become longer, another interface problem appears. What exactly did the system do?

A conventional interaction often leaves obvious traces.

The message appears in Sent. The file gets a version. The transaction appears in history.

An agent can coordinate several services and perform several actions before returning. The end result alone may not explain the process.

That means agentic products increasingly need an action trail rather than simply a conversation transcript. Not internal debugging output.

A useful human account:

• What did you change?
• Where?
• Why?
• What failed?
• What did you leave untouched?
• What still requires me?

Trust may depend less on personality than boundaries

A large amount of attention in AI design goes into whether an assistant feels conversational, natural or human. Those things matter. But for systems that act, I suspect trust will increasingly come from something more mundane.

Predictability.

• Does the agent stay within the task I delegated?
• Does it recognise when circumstances have changed?
• Does it stop at the right moments?
• Can I inspect what happened?
• Can I undo what it did?
• Does it distinguish access from authority?

Those properties are not visual polish surrounding the AI. They are the product.

We are beginning to design authority

For decades, interface design has largely focused on giving people controls for telling software what to do. Agentic systems introduce the inverse problem.

We now also need controls for telling software what it is allowed to do without us.

Scopes. Limits. Budgets. Approval thresholds. Exceptions. Reversible actions. Stop controls. Action histories.

These may look less exciting than a conversational interface. But they define the relationship.

Once software can act on our behalf, the most important question is no longer only: What can this system do?

It becomes: What have I actually entrusted it to do?

References

1. OpenAI Help Centre, “Using cloud browser in ChatGPT”. Source
2. GitHub Docs, “Risks and mitigations for GitHub Copilot cloud agent”. Source
3. GitHub Docs, “Integrating agentic AI into your enterprise's software development lifecycle”. Source
4. GitHub Docs, “Managing issues and pull requests with the GitHub Copilot app”. Source

A product team needs a new component. The design-system team says an existing component almost solves the problem. The product designer says “almost” is precisely the issue. Engineering does not want another implementation. Accessibility identifies behaviour that neither proposal handles properly. Another team appears with a similar requirement, but not quite the same one.

Eventually someone asks:

Should this go into the design system?

It sounds like a component question. Often, it is actually a question about authority.

• Who is allowed to make this decision locally?
• When does that decision become shared?
• What evidence is required before everyone else inherits it?

Components are evidence of decisions already made

A button in a mature design system represents far more than a rectangle with a label. Somebody has already made decisions about interaction states.

Spacing. Typography. Focus behaviour. Keyboard interaction. Contrast. Disabled states. Touch targets. Implementation. Usage. Possibly analytics and localisation.

When a product team consumes that button, it receives all of those decisions together. This is where much of the leverage comes from. The organisation stops repeatedly solving problems it has already solved.

But there is another side to that efficiency. Every shared decision removes some local freedom. That makes a design system an organisational mechanism for allocating decision rights.

Standardisation always draws a boundary

Imagine two extremes.

In the first organisation, every team can invent whatever it needs. Local speed is high. The cost appears later through duplication, inconsistent behaviour, fragmented implementation and repeated accessibility work.

At the opposite extreme, nothing can change without the central system team. Consistency is high. Now experimentation slows, context gets flattened and the system becomes a bottleneck.

Neither extreme is especially attractive. The real work is deciding where the boundary belongs.

Some decisions should be global. Some should belong to a platform. Some belong to a product family. Some should remain intentionally local.

This makes a mature design system less like a catalogue and more like a negotiated boundary between autonomy and coherence.

GOV.UK makes the burden of proof unusually visible

Most organisations do this negotiation internally. GOV.UK exposes a substantial part of it publicly.

A new proposed component or pattern first needs to demonstrate that it is useful to multiple teams or services and unique relative to what already exists.

Before publication, the implementation is reviewed for usability, consistency and versatility, including evidence from user research and testing with disabled users.[1]

Look at what the process is actually doing. A single team is free to encounter a problem. That does not automatically give the solution authority over every other team.

The burden of proof rises when the scope of the decision rises. That is the negotiation.

This suggests a useful principle:

Governance should increase with blast radius.

Changing a local component affects one context. Changing a component used by fifty products affects fifty contexts. Those decisions should not require the same level of evidence.

That sounds obvious when stated plainly. In practice, organisations frequently treat both directions badly.

Sometimes tiny local deviations require central approval. Elsewhere, major shared components enter the system because one influential team needed them quickly.

The process becomes political because the decision boundary has never been made explicit.

There is another path: let the pattern mature in the product

GitHub's Primer documents a particularly interesting route for new components. Its guidance describes an “on-ramp from product to Primer”: a component can first exist as a custom component inside a feature team's application and then move towards the shared system as it matures and gains broader usage.[2]

That reverses a common assumption. Not every potentially reusable component needs to begin its life as a system component.

Sometimes the responsible path is:

solve the specific problem, observe it, learn from actual usage, discover other contexts, then generalise.

Primer's wider contribution guidance also recognises several routes into the system, including discussions, pattern proposals, documentation changes, prototypes, testing and open-source contributions.[3]

The model differs from GOV.UK's. The underlying problem is the same.

How does a local decision acquire enough evidence and legitimacy to become shared infrastructure?

This is where “flexibility” gets dangerous

The natural compromise is to make the shared component flexible enough for everyone.

• Add a prop.
• Add another variant.
• Add a configuration.
• Add an override.

Eventually the component supports fifteen behaviours that were individually reasonable and collectively incomprehensible. This is a negotiation failure disguised as technical flexibility.

Instead of deciding which behaviours actually belong in the shared abstraction, the system stores every disagreement as configuration. The component becomes the fossil record of unresolved organisational decisions.

A mature system sometimes needs to say:

• That behaviour belongs here.
• That variation belongs locally.
• These two use cases are not actually the same component.

Or: We do not yet understand this problem well enough to standardise it.

Those are design decisions too.

The system needs a way to change its mind

There is another reason governance matters. Standardisation makes decisions durable. That is useful until the decision becomes wrong.

Technology changes. Platforms change. Accessibility guidance changes. Product expectations change. The organisation itself changes.

If introducing a shared decision requires evidence, retiring one should require deliberate work too. Otherwise the system accumulates rules that nobody still believes in, but everyone continues following because they are encoded in components.

The healthiest systems are not merely good at accepting contributions. They are good at renegotiating previous decisions.

Measure the quality of negotiation, not the size of the library

Component count tells us very little about system maturity. Even adoption is incomplete.

I would rather know:

• Can teams understand why a shared decision exists?
• Can they identify when their problem genuinely falls outside it?
• Can they propose a change without needing a personal relationship with the system team?
• Can local experimentation happen without fragmenting the entire product?
• Can repeated local patterns graduate into the shared system?
• Can obsolete shared decisions leave it?

Those questions tell us more about the health of the system than the size of its component catalogue.

Consistency is the result

Consistency matters. Users benefit when basic behaviours remain predictable. Engineers benefit from not rebuilding solved interactions. Designers gain time when foundational decisions do not have to be remade for every feature.

But consistency is not the most interesting thing the system creates. Consistency is what we see when enough teams agree to share enough decisions.

The deeper product of a mature design system is the mechanism by which those decisions can be adopted, questioned, improved and occasionally rejected.

That is why some of the hardest design-system conversations begin with five deceptively simple words:

“Our case is slightly different.”

Sometimes it isn't. Sometimes it genuinely is. The quality of the system depends on being able to tell the difference.

References

1. GOV.UK Design System, “Contribution criteria”. Source
2. Primer, “Adding new components”. Source
3. Primer, “How to contribute”. Source

There are sentences every product designer eventually hears from an engineer.

• “We don't know until the request completes.”
• “That value can change while the user is here.”
• “We cannot update those independently.”
• “The provider has not responded yet.”
• “If they close this now, the changes have not reached the server.”
• “This process runs in the background.”

The sentence normally arrives as an explanation of how the system works. The interesting part comes afterwards.

What does the interface do with that information?

Because the moment a technical condition changes what the user can understand, trust or do next, it stops being purely an implementation detail.

System truth and interface truth

Every interactive product is presenting a version of reality.

• The button says the file is saved.
• The price says the item costs €80.
• The progress indicator says something is processing.
• The green tick says the operation succeeded.

Behind those representations is another state: what the system actually knows. When those two states align, nobody notices. When they diverge, we get a product problem.

• A file looks saved but is still local.
• A product appears available but inventory has expired.
• An action appears finished but the job is still running.
• A filter looks applied while an older network request is actually controlling the results.

The useful design question is therefore not simply: What is the technical constraint?

It is: What does the interface currently imply that the system cannot guarantee?

Figma does not need to teach users about IndexedDB

Take losing an internet connection while working in Figma. The technical story is not simple.

Figma is cloud-based. When connectivity disappears, the application can store changes locally in the browser and later synchronise them when the connection returns. Figma documents that it surfaces an offline indicator, an unsaved-changes notification and, where necessary, a flow for synchronising those offline edits later.[1]

The user does not need to understand the local persistence mechanism. They need to understand something much smaller:

Your latest work exists, but it has not reached the shared system yet.

That is the product translation.

I find it useful to think about technical constraints in three ways.

Some should remain completely concealed. Users do not need to know about every cache, request, replica or background service.

Some need to be translated. “Your changes haven't synced yet” is a translation of a technical state into a product state.

And occasionally the constraint needs to be explicitly exposed because understanding it changes the user's decision.

• “This price is no longer available.”
• “Results may be incomplete.”
• “This operation will continue after you leave.”

The challenge is knowing which treatment is appropriate.

A useful threshold

The question I keep returning to is:

Does understanding this constraint change what the user should do?

If the answer is no, the infrastructure should probably stay invisible. If the answer is yes, hiding it starts to become misleading.

That is where architecture enters the interaction.

A loading spinner can hide too much

Consider a process containing several dependent operations. A spinner communicates that something has not finished. It communicates almost nothing about why.

For a simple operation that may be enough. For a system where dependency matters, it can be inadequate.

GitHub Actions handles this differently. Every workflow run can generate a real-time visualisation graph. Jobs appear with their individual statuses, while lines show dependencies between them.[2]

Here the structure of the system becomes part of the interface because the structure is useful.

A developer may need to know that deployment is not simply “slow”. It is waiting because another job has not completed.

Those are very different explanations.

Latency changes more than speed

Suppose a filter applies remotely and takes three seconds to return. It is easy to treat this as a performance problem. Then the interaction begins.

• Can the user select another filter while the first request is running?
• If they do, which response wins?
• Can responses arrive out of sequence?
• Is the displayed result count associated with the old state or the new one?
• Do we optimistically update the control before the backend confirms it?
• What happens when the request fails?

The delay has now affected causality. It changes whether someone can understand which action produced the state they are seeing. A spinner cannot solve that on its own.

The real design problem is state coherence.

Product truth has a cost

Products naturally want to appear fast, stable and simple. That instinct is healthy until simplicity starts creating false certainty.

• The price changes at the final step.
• The upload looked finished but was not.
• The supposedly saved change disappears.
• The result count describes an earlier query.

Each mismatch asks the user to revise their understanding of what the interface means. One mismatch is normally survivable. Repeated mismatches teach people not to trust the product's representations.

There is an important distinction here. Good design hides irrelevant implementation complexity. Good design should not hide relevant uncertainty.

Constraints can produce the interaction rather than merely damage it

This is also why I do not think constraints should always be framed as compromises.

• Offline behaviour forces us to think seriously about local and remote state.
• Long-running operations force us to design asynchronous workflows.
• Changing inventory forces us to think about freshness.
• Platform differences force us to reconsider how an interaction should behave rather than blindly reproduce another platform.

Sometimes the wrong question is:

How do we preserve the design despite this constraint?

A better question is:

What interaction becomes appropriate because this constraint exists?

That change in framing is small. But it often produces a more truthful product.

When infrastructure becomes UX

When a technical limitation appears, I use four questions.

• What does the system actually know?
• What does the interface currently claim?
• What does the user therefore believe?
• Would the difference change their next decision?

If the last answer is yes, we are no longer discussing an implementation detail. The infrastructure has entered the experience.

References

1. Figma Help Centre, “What can I do offline in Figma?”. Source
2. GitHub Docs, “Using the visualization graph”. Source

You have found the flight. The departure time works. The connection is reasonable. The price is inside your budget. You have already entered the passenger details. The next button is obvious. Nothing appears broken.

And yet you go backwards.

You check the date again. You confirm that you are departing from the airport you think you are. You reopen the baggage conditions. You look at the fare rules. Maybe you open the airline's website in another tab. Then you return to the booking.

We normally interpret behaviour like this as friction. Sometimes it is. But there is another possibility: the interface is usable, while the decision is not yet comfortable.

That distinction deserves more attention.

The moment after usability

A great deal of product design is built around helping people understand what they can do and making it easier to do it.

• Can I find the action?
• Do I understand the terminology?
• Can I complete the task?
• Can I recover if something goes wrong?

Those questions are fundamental. But they do not describe everything happening when someone makes a consequential decision.

Someone buying a €12 cable and someone purchasing a €1,200 flight may use familiar interface patterns, but they are not psychologically doing the same thing. The cost of being wrong is different. The amount of verification is different. The need for certainty is different.

Usability can get someone to the final step. It does not necessarily get them across it. There is a space between understanding an action and being comfortable enough to take it.

I think of that as the reassurance gap.

Watch what people do when they are uncertain

One of the most useful indicators of uncertainty is repetition.

• People reread things.
• They go back.
• They reopen collapsed information.
• They compare details they have already seen.
• They leave the product to verify information elsewhere.
• They ask another person.
• They take a screenshot.

Not every repeated interaction indicates poor usability. Some are verification loops. The person is not trying to discover how the product works. They are trying to reduce the possibility that they have misunderstood something important.

That distinction changes what we design.

If someone repeatedly checks whether checked baggage is included, making the purchase button easier to see does not resolve the uncertainty. If someone repeatedly checks the recipient before a bank transfer, reducing the number of screens is not necessarily an improvement. If somebody wants to know what happens when they cancel an insurance policy, hiding the conditions in the name of simplicity can actually make the experience harder to trust.

There are situations where efficiency and confidence pull in different directions.

Repetition can have a different job the second time

The GOV.UK Design System has a pattern called Check answers. Immediately before a user submits information, the service can display the answers they previously supplied, give them a direct way to change each answer, and then ask them to explicitly submit.

The information is repeated. But GOV.UK describes that repetition as helping users gain confidence that their information has been captured correctly and giving them another opportunity to spot mistakes before submission.[1]

That is an important distinction. The first time an address appears, its purpose may be input. The second time, its purpose is verification.

Same information. Different job.

This gives us a better question than:

Have we already shown this information?

The question becomes:

Does the person need this information again to make the next decision confidently?

Those are not the same standard.

Money makes the reassurance gap easier to see

Financial products make this especially obvious because the consequences are explicit.

Wise's current transfer flow asks the user to choose a recipient and amount, shows fees and delivery estimates, and then provides a transfer review before the user commits. Wise explicitly tells users to check that the transfer details are correct before continuing.[2]

The review screen is technically another step. A pure friction-reduction argument could ask why it exists. But removing it would transfer the cost of speed to the user.

The product is effectively saying:

Before money moves, here is the state of the decision in one place.

Recipient. Amount. Currency. Fees. Delivery.

The user can stop thinking about how information was collected and inspect the transaction they are about to create.

Reassurance has a time dimension too

Uncertainty is not only about whether the information is correct. Sometimes the question is whether it is still correct.

Travel products are full of this problem. Prices change. Availability changes. Cancellation terms differ. Taxes and fees depend on context. A user can therefore understand the information perfectly and still wonder whether it represents the complete commitment.

Airbnb's current guidance describes a detailed price breakdown before a booking is finalised, and its guest terms frame the booking commitment around the total price and other requirements identified during checkout.[3][4]

This is not simply pricing information. At that point in the journey, it becomes commitment information.

Four kinds of uncertainty keep appearing

There is a pattern underneath many of these experiences. People want to know whether they have understood the thing correctly. They want to know whether the information remains valid. They want to understand the consequence of proceeding. And they want to know whether they can recover if they are wrong.

Comprehension. Validity. Consequence. Recoverability.

A product does not have to answer all four questions with equal emphasis. The need grows with the cost of being wrong.

That matters because reassurance can also be badly designed. A warning before every action makes ordinary activity feel dangerous. Three confirmation modals do not automatically make something safer. Five security logos can make a checkout look more suspicious, not less. Lengthy explanations can introduce doubts that did not previously exist.

The goal is not maximum reassurance. It is calibrated reassurance.

This changes how we read behavioural data

Product teams commonly measure conversion, completion, abandonment and time on task. Those metrics tell us important things. But they can miss what happens immediately before commitment.

• How many people reopen the cancellation conditions?
• How frequently do users return to an earlier step without changing anything?
• Which information is expanded repeatedly?
• Where do people leave the product and come back?
• Which questions repeatedly reach support teams just before purchase?

Those behaviours can indicate uncertainty even when the interface remains completely functional.

Instead of only asking: Where are people struggling?

we can also ask: Where are people checking?

That creates a different picture of the experience.

Designing confidence

A product does more than help somebody perform an action. It helps them decide whether the action is worth performing. As decisions become more expensive, permanent or consequential, that second responsibility becomes harder to ignore.

The best experience is therefore not always the one that gets someone to the end in the fewest interactions. Sometimes the better product is the one that gives them enough certainty that they no longer feel the need to check somewhere else.

And then allows them to continue.

References

1. GOV.UK Design System, “Check answers”. Source
2. Wise Help Centre, “How do I send money with Wise?”. Source
3. Airbnb Help Centre, “Pricing display in the United States”. Source
4. Airbnb Guest Terms / Terms of Service. Source

Not bad in the sense that it does not work. Quite the opposite.

You can describe an idea to an AI coding tool and, within hours, have something surprisingly functional: a utility for organising photographs, a dashboard for tracking expenses, or a tool that generates presentation mock-ups exactly the way you like them.

If you built it for yourself, accessibility might barely enter the conversation.

You know where everything is. You understand the strange icon you used. You know the unlabeled button in the corner exports the file. The colour combination works for you. The keyboard behaviour does not matter to your own workflow because you use a mouse.

And, within reason, that can be fine. Personal software has an audience of one.

“The accessibility assumptions that barely matter when the audience is one become pivotal when the audience becomes everyone else.”

Something changes when you put the tool on the internet. Someone else finds it useful. Then ten people do. You add accounts, authentication, payments, perhaps a subscription.

What began as software for you has become software for people you do not know.

You do not know how they see. You do not know how they move. You do not know whether they navigate with a keyboard, enlarge text, use voice control, rely on a screen reader, or experience the interface differently from you.

AI is dramatically shortening the distance between those two states.

From personal software to public responsibility

The current conversation around AI-assisted development is understandably optimistic. More people can build. Teams can move faster. Designers can create working interfaces. Developers can generate large amounts of implementation from descriptions. Small, specialised pieces of software can exist without needing the economics of a traditional software company.

Those possibilities are real. But democratising software creation has a second consequence: we are not only creating more software. We are creating more software that can become somebody else’s software.

The prototype can become the product remarkably quickly. The internal tool can acquire external users. The weekend experiment can gain a payment screen. Somewhere during that transition, the standard changes.

Accessibility does not suddenly become morally relevant only when money changes hands. Personal tools can be accessible, and their creators may themselves depend on accessible interaction. The point is narrower: once a product is intended for a broader public, the consequences of inaccessible decisions expand, and commercial services may acquire explicit legal obligations.

The threshold changed in Europe

On 28 June 2025, the accessibility requirements of the European Accessibility Act began applying across the European Union. The Directive covers specified products and services including e-commerce, consumer banking, electronic communications and parts of passenger transport. In transport, its scope reaches websites, mobile applications, electronic ticketing, electronic tickets and certain self-service terminals.¹

The Act contains qualifications. Microenterprises providing services are exempt from its requirements, and the Directive contains provisions for fundamental alteration and disproportionate burden. The precise obligation therefore depends on the product, service and circumstances.¹

But the broader direction is difficult to miss. For commercial digital services within scope, accessibility is not simply a backlog item labelled “nice to have”. It becomes part of the conditions under which the service is offered.

“AI lowers the barrier to creating a product. Accessibility reminds us that the barrier to creating a responsible product is higher than getting it to work.”

The timing matters. One development makes interfaces dramatically easier to produce. The other makes it harder to defend excluding people from those interfaces.

The European Commission describes the EAA as establishing common accessibility requirements for key products and services and notes that around 100 million people in the EU live with a disability.² The impact is therefore not an abstract compliance exercise. It concerns whether people can independently buy, bank, communicate, travel and participate in ordinary digital life.

Faster does not mean more accessible

Generative development introduces a tempting assumption: if a model has seen accessibility guidance, perhaps accessibility arrives automatically with the generated code.

The evidence is more complicated. A 2025 empirical study comparing web code generated by GPT-4o and Qwen2.5-Coder with human-written code found that the models often performed well on basic accessibility features such as colour contrast and alternative text, but continued to struggle with more complex issues including ARIA. Feedback-driven techniques improved the results.³

That finding prevents two easy conclusions. AI-generated code is not inherently inaccessible. But AI knowledge of accessibility does not make an interface accessible by guarantee.

Accessibility depends on context. A model can know that an image may need alternative text without knowing whether this particular image is decorative, informative, functional or redundant. It can know ARIA without correctly modelling a novel interaction. It can produce technically valid controls inside a journey that remains confusing or impossible to complete.

“When the cost of producing an interface falls, the cost of a bad default rises.”

A weak component used once is a defect. A weak component embedded in a design system, copied by an agent and instantiated across hundreds of generated screens becomes infrastructure.

Accessibility is architecture

This is why accessibility cannot be reduced to contrast checks and alternative text at the end of delivery.

Consider booking a flight. A traveller has to search, filter, compare, understand baggage, select an itinerary, enter passenger information, authenticate, pay, retrieve a ticket and potentially respond to disruption. Individual screens can pass automated checks while the journey as a whole remains difficult or impossible to complete.

The EAA is relevant here precisely because it reaches functional parts of commercial services, including e-commerce and passenger-transport interactions.¹ Accessibility has to survive the journey, not merely the component audit.

WCAG makes the architectural point explicit. Its “Robust” principle requires content to be interpretable by a wide variety of user agents, including assistive technologies. Success Criterion 4.1.2 requires interface components to expose programmatically determinable names and roles, as well as states and values where relevant.⁴

That means a visual interface has always had another representation underneath it. A heading is not merely large text. A button is not merely a rectangle. A checkbox has a state. A form control has a name. The semantics are part of the interface.

Then something unexpected happens

Those semantics now have another audience.

Chrome’s documentation for agentic browsing explicitly describes “accessibility for agents”. It explains that agents can use the accessibility tree to identify and understand interactive elements, and that missing accessible information can create problems for both assistive-technology users and agents.⁵

This is not because accessibility standards were secretly designed for AI. They were not. It is because both assistive technology and some agents benefit from meaning that survives beyond visual appearance.

A custom clickable with an icon may be obvious to a sighted mouse user while exposing little useful information programmatically. A native button with an accurate accessible name carries its purpose into another layer of the system.

“The web spent decades learning how to make interfaces understandable beyond pixels. Agents have unexpectedly become another consumer of that work.”

This creates an additional incentive for semantic quality, but it should not replace the original reason for doing the work. Accessibility is for people. The fact that machines also benefit is a consequence, not the justification.

Do not confuse the beneficiaries

“Agent accessible” and “human accessible” are not synonyms.

A visual computer-use agent may successfully click an unlabeled icon that remains inaccessible to a screen-reader user. A perfectly labelled form may be easy for software to parse while still being exhausting for someone with a cognitive disability. A machine-readable action can still have terrible contrast. A structured API can be flawless while the human product built on top of it remains impossible to navigate with a keyboard.

The overlap is useful, but the experiences are different.

It is therefore helpful to distinguish three layers: human perceptual and interaction accessibility; semantic accessibility that exposes meaning programmatically; and explicit agent interoperability, where systems expose actions or tools directly rather than forcing software to reconstruct every task through the human interface.

These layers can reinforce one another, but none proves the others.

Design for the system, not the demo

The practical response is not to append “make it accessible” to the end of an AI prompt.

Accessibility needs to be encoded into the environment from which software is generated: components with correct semantics and keyboard behaviour, tokens that preserve contrast, content patterns, linting, automated tests, agent instructions, acceptance criteria, code review and testing with people who actually use assistive technologies.

If an accessible component library is the easiest thing for an agent to use, generation begins from a stronger default. If the design system contains inaccessible custom controls, the agent can reproduce those just as efficiently.

“AI can accelerate implementation. It does not outsource responsibility.”

This is one of the more important consequences of the EAA for teams adopting AI development tools. The organisation deploying the service still owns the outcome. The origin of the code does not change the experience of the person who cannot use it.

Accessible by default is not accessible by guarantee

Even strong foundations are not enough on their own.

Components can be accessible individually and inaccessible in combination. A dialog can manage focus correctly while appearing at the wrong moment. Every image can have alternative text while the descriptions are useless. Every heading can use valid markup while the information architecture remains incoherent.

Accessibility is partly a property of components. It is also a property of relationships, tasks and lived experience.

That is why an agent can help test accessibility without becoming the final authority on it. Automated evaluation is valuable. Human experience remains the system we are trying to support.

The new meaning of robust

There is an optimistic interpretation of this convergence.

For years, accessibility advocates have argued for semantic HTML, meaningful labels, predictable interaction, structured content and standards-based controls. These practices were sometimes treated as specialist requirements.

Now some of the same qualities also make products easier for machines to understand. That creates an additional economic incentive for work that should already have been happening.

The cynical version is uncomfortable: organisations may become interested in semantics because agents affect automation, discoverability or revenue. But the direction of the argument matters. Accessibility should not become valuable because machines need it.

“An interface that only communicates through appearance is an incomplete interface.”

WCAG’s word “robust” is becoming unexpectedly useful. The digital environment now contains browsers, assistive technologies, humans, visual agents, semantic agents and increasingly explicit machine-facing capabilities. Products have more than one surface.

The screen is one. The accessibility tree is another. The underlying capabilities may become another still.

The challenge of the AI era is not simply teaching machines how to use the web. It is making sure that, while we teach machines to use it and make software easier to create, we do not build a web that leaves people behind.

References

1. Directive (EU) 2019/882 of the European Parliament and of the Council, 17 April 2019, European Accessibility Act. Source
2. European Commission, “The EU becomes more accessible for all”, 31 July 2025. Source
3. Hyunjae Suh, Mahan Tafreshipour, Sam Malek and Iftekhar Ahmed, “Human or LLM? A Comparative Study on Accessible Code Generation Capability”, 2025. Source
4. W3C, Web Content Accessibility Guidelines (WCAG) 2.2, Principle 4: Robust and Success Criterion 4.1.2 Name, Role, Value. Source
5. Chrome for Developers, “Accessibility for agents”, 2026. Source

The tools changed, but the relationship stayed the same. The software defined the workflow. Designers learned its capabilities, interfaces and limitations.

Then the applications grew.

Drawing became prototyping. Prototyping became collaboration, documentation, handoff, presentations, asset generation and code. General-purpose tools became platforms because software was expensive to build and broad products were easier to justify.

AI is changing that logic.

As software becomes cheaper to create, the minimum useful audience for a tool gets smaller. At the same time, major platforms are becoming more programmable and increasingly able to act through AI.

The result is not simply that new AI products replace old applications. The more important shift is that design tools stop being fixed destinations. They become adaptable systems: platforms that agents can connect to, small utilities that teams can generate, and interfaces that can be shaped around a particular problem.

Software that does not need to become a product

Imagine a tool that generates one specific kind of presentation mock-up. It places production components into a defined composition, applies a small set of visual treatments and exports the result.

There may be no market for it. It may only serve one team.

Previously, that would have been enough reason not to build it. Now the calculation is changing: for some narrow tasks, creating the utility can become easier than repeatedly working around its absence.

This idea has a longer intellectual history than the current AI boom. Ink & Switch describes “malleable software” as an ecosystem in which people can adapt tools to their own needs with much less friction, rather than continually adapting their workflows to fixed applications. [1]

Generative development gives that ambition a new practical route. It lowers some of the effort required to move from an idea for a tool to a working interface. That does not eliminate engineering, maintenance or quality concerns. It does change which ideas are worth trying.

For designers, the question starts to move from “Which tool should I use?” towards “What tool would make this problem easier?”

“Software begins to behave less like a fixed environment and more like a design material.”

The platforms are adapting too

This is not a rebellion against large applications. The incumbents are responding to the same shift.

Adobe has been adding agentic workflows inside Creative Cloud applications, describing an assistant that can orchestrate multi-step work while keeping outputs editable. Canva AI 2.0 similarly combines conversational creation, agentic editing and Canva Code inside its broader creative environment. Figma Make is moving closer to production code, including workflows that connect a local codebase, support visual edits and annotations, and carry changes through Git and pull-request processes. [2],[3],[4]

Those are company descriptions of their own products, so they should not be read as independent evidence that these approaches are better. They are useful for something narrower: showing that the largest creative platforms are changing their architecture and interaction models in response to the same pressure.

The important change is not that these products contain AI. It is that AI weakens the boundary between intention and operation.

Instead of selecting every command one by one, a designer can increasingly describe an outcome and let the system assemble part of the sequence. Menus and toolbars do not disappear, but they are no longer the only route to capability. Context, constraints and judgement become more important.

“The application remains, but the interface is no longer the whole product.”

Design and development begin to converge

Product work has traditionally involved at least two representations: a design artefact and an implementation. Much of the industry's infrastructure exists to manage the distance between them.

Design systems, tokens, documentation, developer modes, specifications and handoff all help one representation survive its translation into another.

AI-assisted development makes that separation less rigid.

Paper is useful here as an example of a younger hybrid environment. Its documentation supports importing HTML into the design environment and connecting AI agents directly to design files through MCP. Figma is approaching the same broad problem from the other direction: its Make workflow can connect visual editing to an existing codebase, while its MCP tooling can move structured design context into development environments and write native content back to the canvas. [4],[5],[6]

Neither approach makes the traditional canvas obsolete. Nor does either prove that design and development should collapse into a single discipline. They do, however, make the boundary more negotiable.

“How much value is there in maintaining separate representations when design and implementation can increasingly act on shared components, rules and context?”

There are still good reasons for separation. Production code carries architecture, state, performance, accessibility, security and operational constraints that a visual canvas can hide. A design environment also gives people room to explore without prematurely committing to implementation details.

The more plausible change is continuity rather than collapse. A designer can work visually while an engineer works directly with implementation, with both drawing from increasingly shared context.

Tools become connected infrastructure

Model Context Protocol makes this shift easier to see.

Anthropic introduced MCP in November 2024 as an open standard for connecting AI assistants to external systems and data. The protocol has since continued to evolve, including a July 2026 specification revision focused on scalability, extensions and stronger authorisation. [7],[8]

For design, the significance is straightforward. An AI system does not have to understand a design only from pixels or an exported file. Where a tool exposes structured context, an agent can work with components, variables, layout information, resources and actions.

Figma's MCP server, for example, exposes structured design context such as components, variables and layout data to compatible agents, and now supports creating or updating native Figma content in supported workflows. Paper documents a similar connection between AI agents and its design files. [6],[9]

The broader implication is more important than either implementation. Applications become less self-contained.

An agent can sit across boundaries that people previously crossed manually: inspect one system, retrieve context from another, compare an implementation, then create or modify an artefact somewhere else.

“The design tool is no longer just an application with a canvas. It can become the relationship between platforms, protocols, data and task-specific utilities.”

The monoliths will remain

None of this gives us a good reason to assume that large platforms disappear.

Organisations need permissions, version history, governance, security, accessibility, documentation, support and predictable continuity. Small generated tools do not acquire those qualities simply because they are easy to create.

“Cheap software can create cheap technical debt.”

The stronger model is a layered ecosystem. Large applications can remain trusted systems of record while smaller tools handle narrow, temporary or highly specific needs.

The platform provides stability. The custom tool provides adaptability.

There is also a governance cost to agentic interoperability. The MCP ecosystem has spent substantial effort on authorisation and security, including OAuth-based access, token validation and enterprise-managed authorisation. That work exists because a connected agent is more consequential than a passive assistant: access to more tools and data increases both usefulness and the consequences of a mistake. [8],[10]

So the future cannot simply be “connect everything to the model”. Capability without boundaries is not a mature workflow.

What changes for designers

The professional shift may be more important than the technological one.

Software proficiency has often been easy to confuse with design proficiency because it is visible and measurable. But if tools become more adaptive and agents can operate parts of them on our behalf, knowing where every control lives becomes less distinctive.

Judgement becomes more visible.

Understanding the problem. Defining constraints. Recognising quality. Building coherent systems. Detecting when a convincing output is wrong. Knowing what must remain consistent across hundreds of generated variations. Deciding where automation helps and where deliberate human intervention matters.

These have always been design skills. More capable tools simply expose how important they were all along.

A designer who cannot use the tools of the job still has a practical disadvantage. But a designer whose main advantage is operating a particular interface efficiently has a different problem.

“The interface can increasingly operate itself. Judgement cannot.”

After the monolith

The future of creative software is unlikely to resolve into one winning interface.

Large platforms, specialist applications, generated utilities and temporary interfaces can coexist. Some tools will begin with a canvas. Others with code. Some will be operated primarily by people; others increasingly through agents. Some will exist only long enough to solve one problem.

The major platforms may therefore become less like sealed destinations and more like durable infrastructure that other tools and agents can use.

“This is not the end of design software. It is the loosening of its boundaries.”

For most of our careers, designers adapted themselves to the tools available to them. We learned their abstractions, accepted their workflows and invented workarounds for their limitations.

Now that relationship can become more reciprocal.

The tool can adapt to the designer.

And if creating a new tool becomes cheap enough, the most interesting question may no longer be which application wins.

“What would you make if the tool you needed did not have to exist yet?”

References

1. Geoffrey Litt, Josh Horowitz, Peter van Hardenberg and Todd Matthews, “Malleable Software: Restoring User Agency in a World of Locked-Down Apps”, Ink & Switch, June 2025. Source
2. Adobe, “More time to spend on your craft: Adobe brings the power of its creative agent to Creative Cloud apps”, 18 June 2026. Source
3. Canva, “Introducing Canva AI 2.0: Reimagining how the world creates”, 2026. Source
4. Iris Lin and Jesse Lumarie, “Figma Make, now on your local code”, Figma, 28 May 2026. Source
5. Paper, product documentation. Source
6. Figma, “Guide to the Figma MCP server”. Source
7. Anthropic, “Introducing the Model Context Protocol”, 25 November 2024. Source
8. Model Context Protocol maintainers, “The 2026-07-28 Specification”, 28 July 2026. Source
9. Figma, “Get started with the Figma MCP server”. Source
10. Model Context Protocol, authorisation and enterprise authorisation documentation, 2026. Source

Clarity usually starts before the interface. It starts with understanding who needs to act, what information they need, what can safely be deferred, and where mistakes become expensive. A good workflow design makes those boundaries explicit instead of forcing people to reconstruct the process from scattered screens.

In practice, this means shaping the flow around sequence and confidence. The interface should show where someone is, what has already happened, what still needs attention, and what will happen next. Labels should describe work in the language people use, not only the language of the data model.

Complex products also need good recovery paths. Empty states, validation messages, review screens, and permission boundaries are not secondary details. They are where the product explains itself when the happy path breaks.

The best complex workflows do not feel simple. They feel held together. They give people enough context to move forward, enough feedback to trust the system, and enough structure to complete the work without carrying the whole process in memory.

The stronger version of growth work asks why people hesitate in the first place. Do they understand the value? Are they being asked for commitment too early? Is the next action clear? Does the product create confidence before it asks for attention, data, or payment?

This kind of work sits between research, interaction design, content, measurement, and delivery. It may lead to a better entry point, a more honest prompt, a clearer comparison, a softer reminder, or a flow that explains the benefit before asking someone to opt in.

The difference is intent. Shallow optimisation tries to make the same moment harder to ignore. Product-led growth tries to make the moment more useful. It respects the user's context and improves the conditions around the decision.

That is why good growth design often looks quieter than expected. It removes friction, clarifies tradeoffs, closes feedback loops, and helps the product earn the next step rather than forcing it.

When accessibility is part of product quality, it becomes a normal design constraint. It informs whether a form is understandable, whether a comparison is readable, whether a state change is announced clearly, and whether a task can be completed without relying on a single input method or visual cue.

That shift changes the work. Designers make components with accessible states built in. Engineers have clearer acceptance criteria. Product teams can talk about usability risk before it becomes technical debt. The goal is not to make every conversation about compliance. The goal is to make the accessible path the default path.

Small product habits matter here: naming states clearly, designing keyboard paths, checking contrast in real brand contexts, writing labels that explain intent, and reviewing flows under stress. These habits create systems that are easier for more people to use, and they also improve quality for everyone else.

Good accessibility work is rarely loud. It shows up as fewer dead ends, clearer choices, stronger defaults, and interfaces that respect different ways of moving through a product.

As products grow, the system has to absorb more pressure. New flows introduce edge cases. Brand needs become more specific. Engineering constraints change. Teams interpret patterns differently. Without a shared operating model, the system can become either too rigid to use or too loose to trust.

Useful systems make the important choices visible. They explain where a pattern should be reused, where variation is acceptable, and what tradeoffs sit behind the decision. Tokens, components, documentation, contribution models, and review rituals all matter because they help people make consistent decisions at different levels of detail.

Governance is part of the design work, not an administrative layer around it. A system needs clear ownership, lightweight contribution paths, and enough product context to evolve with the teams using it. Otherwise, the library may remain tidy while the product experience drifts.

The most durable systems feel practical. They give teams a shared language, reduce repeated decisions, and leave room for the product to grow without redesigning the foundations every time the organisation changes shape.