Part III orientation
Part I established the evidence and central thesis. Part II translated that thesis into architecture, failure models, verification patterns and real-world workflows. Part III addresses the governance of capability: how much autonomy an assistive agent should receive, how security and privacy controls should work, how trust can be calibrated, how standards and procurement may evolve, and what research is still needed before agentic AI can be treated as dependable accessibility infrastructure.
44. Autonomy Is a Spectrum, Not a Switch
Public discussion often divides software into two categories: tools that wait for commands and autonomous agents that act on their own. Real systems occupy a continuum. A screen reader that reads the focused control is reactive. An assistant that answers a question about the current page is interpretive. A system that proposes a sequence but waits for approval is advisory. A system that executes reversible steps and pauses before commitments has bounded autonomy. A system that can pursue goals across applications with broad permissions approaches high autonomy.
This continuum matters for accessibility because the optimal level of autonomy depends on the task, the user and the stakes. There is no single setting called “accessible autonomy.” A person may want very high autonomy for organizing downloaded files and very low autonomy for banking. The same user may want detailed guidance in unfamiliar software and near-silent automation in an application used every day.
A practical autonomy model can be divided into six levels. Level 0: direct access. The user operates the interface through a screen reader or other assistive technology; AI is not involved. Level 1: interpretation. AI describes, summarizes or answers questions but does not act. Level 2: guidance. AI provides context-aware steps while the user executes them. Level 3: bounded action. The agent performs a short, clearly specified sequence and reports the result. Level 4: supervised workflow. The agent plans and executes a multi-step task but pauses at defined decision and commitment points. Level 5: delegated workflow. The agent performs an entire class of tasks under standing rules and alerts the user only when conditions fall outside those rules.
For accessibility, movement between levels should be fluid. A user may begin at Level 2 to learn a new application, move to Level 3 once comfortable, and eventually authorize Level 5 for a repetitive weekly report. If an unexpected situation occurs, the agent should drop to a lower level and ask rather than improvising beyond the user’s rules.
This is a form of progressive trust. Traditional software permissions are binary: allow or deny. Agentic permissions should incorporate scope, consequence and confidence. The user could authorize “create calendar drafts but do not send invitations,” “organize files within this folder but do not delete,” or “purchase this recurring item if the total remains below $40 and delivery is free.” These are operational policies expressed in human terms.
High autonomy is not inherently anti-accessibility. For some users, repeated confirmation can be more disabling than automation. Someone processing hundreds of routine items should not be forced to listen to a confirmation for each one. The key is that autonomy is intentionally granted, constrained and revocable. A user should be able to ask, “What are you authorized to do?” and receive a comprehensible answer.
Agents should also support temporary elevation. A task may require access to a folder or service only for a few minutes. The system can request permission, explain why, use it and then release it. Temporary permission reduces long-term attack surface and makes authorization easier to understand.
The autonomy spectrum also helps organizations design policy. Rather than banning “agents,” an employer can permit Level 1 and Level 2 broadly, Level 3 for approved tools, and higher levels only in environments with logging and least-privilege controls. Accessibility accommodations can be mapped to appropriate levels without forcing every use case through the same security decision.
Most importantly, autonomy should never be confused with independence. A system can act autonomously while making the user dependent on an opaque provider. Conversely, a user can choose extensive delegation while remaining independent if they understand the rules, can inspect outcomes, can switch providers and retain a direct accessible fallback. Independence is about control over the relationship, not the number of clicks personally performed.
45. Consequence-Sensitive Confirmation: When Should an Agent Ask?
One of the hardest interface questions for agents is when to interrupt. Ask too often and automation becomes burdensome. Ask too rarely and the system can make unwanted commitments. Accessibility complicates this because spoken prompts consume attention sequentially. Confirmation design must therefore optimize for significance rather than frequency.
A useful framework considers four variables: reversibility, external effect, sensitivity and ambiguity. Reversibility asks whether the action can easily be undone. Opening a document is reversible; permanently deleting it is not. External effect asks whether the action changes another person’s world: sending a message, placing an order or publishing a post. Sensitivity concerns money, legal status, health, identity, private data or security. Ambiguity measures whether multiple outcomes are reasonable given the user’s instruction.
Actions low on all four dimensions can usually proceed without interruption. Search, scrolling, reading and temporary filtering are examples. Actions high on any dimension deserve more scrutiny. A message sent to an external recipient is externally consequential even if it can theoretically be followed by a correction. A password change is security-sensitive. A purchase is both financial and externally consequential. Choosing among equally priced products is ambiguous even if the purchase itself has not happened yet.
Confirmation should state the decision, not merely ask “Are you sure?” A useful prompt says: “Ready to send this message to Maria Santos and copy Finance. It includes invoice.pdf. Send now?” A poor prompt says: “Confirm action.” The information needed to decide must be inside the accessible prompt so the user does not have to reconstruct context.
For long workflows, confirmation can occur at commitment boundaries rather than every step. An agent can search, compare, fill and validate without interruption, then summarize before final submission. This pattern concentrates attention where it matters. It also makes the user’s mental model simpler: preparation can be automatic, commitment is explicit.
Users should be able to configure standing confirmations. One person may never want an agent to post publicly without review. Another may authorize automatic publication of a specific scheduled feed. A business user may approve invoices under a threshold but require review above it. The agent should make such standing rules visible and easy to revoke.
There is also a case for post-action notification rather than pre-action confirmation. Reversible actions such as moving a file into a folder can proceed, followed by a brief notice with an undo command. This is faster than asking first and still preserves control. Modern user interfaces already use this pattern; agents can adopt it in language form.
Confirmation fatigue is a security risk. If a system interrupts constantly, users learn to approve automatically. Accessibility amplifies this because every unnecessary prompt can disrupt screen-reader flow. Designers should measure not only whether confirmations exist but whether they are informative enough to justify interruption.
46. Prompt Injection and the Blind User’s Verification Burden
Prompt injection is one of the defining security problems of agentic AI. A language model reading untrusted content may encounter text designed to alter its behavior: instructions hidden in a webpage, document or message that attempt to override the user’s goal. In a simple chatbot, this may produce a strange answer. In an agent with tools, it can lead to data exposure or unauthorized action.
The risk is particularly relevant to assistive browsing because the agent often acts as an interpreter of content the user cannot easily inspect visually. A malicious instruction might be rendered in tiny text, offscreen content or metadata. A sighted user supervising a browser agent might notice suspicious behavior. A blind user may depend on the agent’s accessible summary and therefore have less independent evidence of the attack.
The correct defense cannot be “users should be careful.” The system architecture must separate data from authority. Text retrieved from a website should be treated as untrusted content, not as instructions with the same priority as the user’s request. Tool permissions should enforce this distinction even if the model becomes confused. A webpage should never gain permission to send an email merely by telling the agent to do so.
Least privilege limits the blast radius. If a browsing task has access only to public web retrieval, malicious page content cannot reach the user’s files. If a research workflow needs Drive access but not payment access, the payment tool should not be available. Permissions should be granted per workflow and expire when possible.
Agents can also use policy enforcement outside the language model. A transaction engine can require explicit human approval for spending regardless of what the model says. A file tool can block permanent deletion unless a specific confirmation token is present. A connector can restrict the set of recipients or domains. These deterministic controls are stronger than asking a probabilistic model to remember a rule.
Accessible security warnings require careful design. Dumping raw prompt-injection traces into a screen reader can be overwhelming. The system can instead report: “This webpage contained instructions directed at the AI rather than information for you. I ignored them. No external actions were taken.” Advanced users can inspect details if desired.
Prompt injection also reinforces the value of action provenance. If an agent proposes a surprising step, the user should be able to ask why. The explanation can identify the trusted source of the instruction: “You asked me to upload the document,” versus “The webpage requested an upload.” The agent should never imply that untrusted content came from the user.
Security research should include accessibility-specific threat models. Attackers may target users who rely heavily on AI mediation, crafting visual or semantic traps that exploit the gap between what the agent perceives and what the user can independently verify. Defenses should be tested with real blind users to ensure that warnings are understandable without creating constant alarm.
47. Identity, Delegation and the Question of Who Acted
When a human clicks a button, systems generally attribute the action to the human’s account. When an agent clicks on the human’s behalf, attribution becomes more complex. The user authorized the goal, the agent selected the steps, and an application recorded the result. For auditing, security and user trust, systems need to represent this delegation clearly.
NIST’s emerging work on AI-agent identity and authorization highlights this distinction. Agent identities can allow systems to know that an action came through an automated delegate rather than direct human interaction. Authorization can then be scoped: the agent may read certain resources, create drafts or perform transactions only within defined limits.
This is useful for accessibility because it creates a machine-readable boundary around assistance. A user can authorize an agent to manage calendar drafts while reserving final invitation sending for direct approval. Logs can say, “Event drafted by agent under Kaeleb Heck’s authorization; invitation sent by user at 3:14 p.m.” Such records are clearer than treating every action as indistinguishably human.
Delegation should be understandable from the user side as well. Account settings could present permissions in plain language: “This agent can read messages in your Travel label and create calendar events. It cannot send messages, delete email, access payment information or change account security.” The screen should be navigable and compatible with braille and keyboard input.
Revocation must be immediate. If an agent behaves unexpectedly, the user should have a global way to suspend its permissions. This control should not depend on navigating through the agent itself. Operating systems and platforms may eventually need standardized “stop all agent activity” mechanisms analogous to privacy or accessibility shortcuts.
Delegation also creates organizational accountability questions. Employers should not hold workers responsible for hidden agent behavior they had no reasonable way to observe. Conversely, users should not be able to disclaim intentional actions merely because an agent executed them. Clear logs and permission boundaries help distinguish these cases.
Identity systems must avoid turning disability accommodation into a permanent marker visible across an organization. An agent may be used because of accessibility, productivity or preference. Logs can record that automation occurred without unnecessarily recording medical or disability information. This is another example of data minimization serving dignity as well as security.
48. Privacy, Memory and the Cost of Personalization
Agentic AI becomes more useful as it learns preferences and gains context. It may remember that a user prefers aisle seats, wants concise screen-reader output, avoids early flights, uses a particular citation style or requires confirmation before external messages. These memories reduce friction. They can also form a detailed profile of a person’s routines, relationships and disability-related needs.
Accessibility personalization should therefore follow a minimum-necessary principle. The system needs to remember that the user prefers short status updates; it may not need to store why. It can remember a preferred navigation style without recording a diagnosis. It can store a travel preference without inferring health information.
Users should be able to inspect what the agent remembers in an accessible format. Memory should not be a mysterious personalization layer. A user could ask, “What preferences are you using for travel?” and receive a list. They should be able to edit or delete individual items and distinguish temporary session context from persistent memory.
Visual agents raise additional privacy concerns because cameras and screenshots capture more than the intended target. A blind user photographing a letter may accidentally include a nearby ID card or another person. Framing assistance can reduce accidental capture. Local cropping or OCR can reduce how much data leaves the device. The application should make retention and training policies clear in accessible language.
Workplace memory deserves extra caution. An enterprise agent might learn that an employee frequently requests explanations of inaccessible dashboards. That information should not become a performance signal or informal record of disability. Organizations should establish boundaries between personalization data and managerial analytics.
Memory can also create security risk if preferences are treated as unquestionable commands. An attacker who modifies stored instructions could change the agent’s behavior across sessions. Sensitive standing rules should have integrity protection and change history. The user should be notified when consequential preferences are modified.
The tension between personalization and privacy does not require abandoning memory. It requires user-visible control. Accessibility has long relied on personal configuration. The innovation is to make semantic preferences as inspectable and portable as speech rate or braille settings.
49. Trust Calibration and the Difference Between Fluency and Reliability
Agentic systems communicate in natural language, and natural language can disguise uncertainty. A polished sentence feels more deliberate than a raw error code. That fluency can cause users to overestimate reliability, especially when the system gives detailed explanations after the fact.
Blind users already have substantial experience evaluating mediated information. Screen-reader users learn which websites are unreliable, which OCR tools handle particular documents well and which visual-description systems need verification. Generative AI adds a system whose capabilities vary not only by task but by model update, prompt, context and tool state.
Trust calibration means aligning confidence with actual performance. Interfaces can help by separating verified facts from model interpretations. A travel agent can mark a baggage allowance as “confirmed from airline fare rules” while labeling an estimate of airport walking difficulty as “inferred from map and terminal information.” A visual assistant can say that text was read directly by OCR while an object description is model-generated.
Confidence scores can be useful only if calibrated and understandable. A meaningless “92% confident” badge may create false precision. Qualitative explanations of evidence can be more informative: “I found the same departure time on the airline and airport websites,” or “I can see only part of the label, so this answer may be incomplete.”
Trust also depends on predictable refusal. If an agent sometimes acts despite uncertainty and sometimes asks, users cannot form a stable mental model. Policies should define categories in which the agent always pauses. Consistency lets users delegate confidently without constantly supervising.
Corrections should update trust without becoming punitive. When the user says, “That is the wrong file,” the agent should identify why it selected the file, correct the target and, where appropriate, update a preference. It should not bury the error in a verbose apology. Effective recovery is more valuable than performative certainty.
Long-term studies are needed because trust develops over weeks and months. A laboratory participant may be cautious with an unfamiliar prototype. A daily user may automate approvals after repeated success. Rare high-severity failures can occur only after substantial use. Agentic accessibility research should therefore include longitudinal deployment, not only short task batteries.
50. Cognitive Load: When Assistance Becomes Another Interface to Manage
AI can reduce mechanical interaction while increasing cognitive complexity. The user must formulate goals, interpret the agent’s output, monitor uncertainty, decide when to intervene and maintain a mental model of what the system is doing. For screen-reader users, this management occurs through a serial audio or braille channel that is already carrying application information.
The 2026 conversational-browsing study reported increased cognitive demand even when users experienced benefits. Coding-assistant research found that blind developers could become overwhelmed by excessive suggestions and context switching. These findings caution against the assumption that fewer keystrokes automatically mean less effort.
Agent interfaces should therefore minimize coordination overhead. The user should not need to remember a special syntax. Goals can be expressed naturally. Status should be concise. The agent can maintain task context so the user does not have to repeat constraints. Interruptions should correspond to meaningful decisions.
Output chunking is important. A long list of twenty search results may be technically accessible but hard to compare in speech. The agent can first summarize the top three and offer to expand. Tables can be converted into structured comparisons. Users should be able to request “just the differences” or “give me the full details.”
Mode confusion is another source of load. Users need to know whether the agent is merely explaining or actually acting. The interface should have distinct language and perhaps distinct controls for advisory versus action modes. “You could click Submit” is not the same as “I am about to click Submit.” Ambiguity can be dangerous.
Interruptibility should be two-way. The user can stop the agent, and the agent can pause itself when it reaches uncertainty. A paused state should be stable; the user should be able to explore the interface with the screen reader and then resume without losing context.
Cognitive accessibility also benefits from summaries at boundaries. At the end of a workflow, the agent can say what was completed, what remains and whether any follow-up is needed. This closes the loop and reduces the burden of reconstructing events from memory.
51. Standards: What Existing Accessibility Guidance Covers—and What It Does Not
WCAG 2.2 provides an essential foundation for web content. Its requirements around text alternatives, keyboard access, focus, labels, status messages and robust semantics directly improve agent-assisted environments as well as conventional screen-reader access. But WCAG was not designed to specify how an autonomous system should explain its plan, request confirmation or expose an action history.
Agentic accessibility therefore creates a new standards layer. The underlying website still needs WCAG. The agent interface also needs WCAG. Beyond that, human-agent interaction needs requirements about delegation and oversight. These might eventually address accessible planning summaries, decision-point presentation, interruption, provenance, reversible actions, permission transparency and accessible verification evidence.
Existing AI risk frameworks supply complementary concepts. NIST’s AI RMF emphasizes governance, mapping context, measurement and management, along with reliability, safety, security, transparency, explainability, privacy and fairness. The UC Berkeley agentic profile translates these principles into more agent-specific controls such as intervention, containment, logging and shutdown. Accessibility standards can connect these controls to user-interface requirements.
For example, a risk framework may say that human intervention must be possible. Accessibility guidance should add that the intervention control must be perceivable and operable through assistive technology, available through a stable mechanism, and not visually dependent. A framework may require logging. Accessibility guidance can require that the user-facing action history be structured, navigable and understandable.
Standards should avoid prescribing one modality. Voice-only confirmation is not sufficient for deafblind users or people who prefer braille. Visual-only agent traces are not sufficient for blind users. The goal is multimodal equivalence and programmatic exposure.
Agent evaluation standards also need real disability participation. Simulating screen-reader use by disabling the mouse misses expertise, shortcuts, braille and adaptive strategies. A11y-CUA is valuable partly because it records real interaction traces. Standard test suites should include tasks designed and validated with disabled users.
The standards process will necessarily lag product innovation. In the meantime, developers can adopt the principles in this monograph as design targets and document deviations. Early conventions can eventually mature into interoperable requirements.
52. Procurement and the Power of Institutional Requirements
Accessibility often improves when major purchasers demand it. Governments, universities, enterprises and platforms can influence vendors by making accessibility a condition of procurement. Agentic AI should be added to that conversation before inaccessible interaction patterns become entrenched.
A procurement review can ask whether the AI chat and agent controls work with major screen readers; whether keyboard users can access every function; whether progress and errors are programmatically exposed; whether action histories are available; whether the user can interrupt the agent; whether confirmations identify the actual consequence; and whether the system supports high-contrast and magnification settings.
The review should also examine tool permissions and data practices. Does the agent require broad account access for simple tasks? Can permissions be scoped? Are screenshots retained? Can the organization disable certain tools? Can action logs be exported for audit? Are user preferences portable?
Vendor claims should be tested rather than accepted at face value. Automated accessibility scans are useful but incomplete. Human testing with disabled users is necessary, particularly for dynamic agent interactions. A product can have technically labeled controls while still imposing unusable cognitive or verification burdens.
Procurement can encourage interoperability by preferring systems that expose standard APIs and accessible semantic state. Proprietary visual automation may work today and fail after an interface change. Structured interfaces and documented permissions are more durable.
Institutions should also plan for service continuity. If an AI vendor experiences an outage, disabled users should not lose access to essential functions. Native accessibility and non-AI fallbacks remain part of resilience. This is another reason not to treat agentic mediation as a replacement for standards-based access.
53. Global Equity: Capability Is Not Access
The strongest AI models can create an illusion that the accessibility problem has been solved because demonstrations are impressive. But capability in a laboratory or premium service is not the same as access in everyday life. Device cost, subscription price, language support, bandwidth, institutional policy and assistive-technology availability determine who benefits.
The ILO and ATscale have reported stark disparities in assistive-technology access between lower-income and high-income settings. Agentic AI may reduce the cost of some specialized functions by using mainstream hardware, yet advanced models often require cloud infrastructure and ongoing payment. The economic model could therefore reproduce inequality in a new form.
Offline resilience is important. Basic screen-reader access works without a cloud model. Essential AI features should degrade gracefully when connectivity is weak. Smaller on-device models can handle OCR, basic classification, local search and privacy-sensitive tasks, escalating to cloud services only when necessary.
Multilingual capability must be measured in context. The 2025 ACL visual-assistance evaluation found weaknesses in multilingual and cultural understanding. Local-language accessibility requires more than translation. Terminology, scripts, products, signs, social conventions and assistive practices vary across regions.
Global research also needs broader recruitment. Many studies involve technically experienced participants in North America or Europe. Findings may not generalize to users with less formal training, older devices or different screen-reader ecosystems. Community organizations can help define relevant tasks and evaluate systems in real conditions.
Equity also concerns which problems receive investment. Commercial AI will naturally prioritize large markets. Disability-led funding can support low-volume but high-impact needs, open datasets and public infrastructure. The most transformative accessible agents may emerge where commercial incentives are weakest.
54. Evaluation Science for Accessible Agents
If accessible-agent evaluation uses only traditional automation benchmarks, it will miss what matters most. A benchmark might award success when a product reaches a shopping cart, even though the agent chose an arbitrary flavor. It might award success when a message is sent, even though the user did not know an attachment was included. Accessibility requires a richer definition of success.
A comprehensive evaluation should measure at least five layers: outcome, process, user control, accessibility compatibility and consequence. Outcome asks whether the correct end state was reached. Process measures efficiency, errors, retries and grounding. User control measures whether important decisions were surfaced and whether intervention worked. Accessibility compatibility examines screen-reader, braille, magnification and keyboard behavior. Consequence weights errors by severity.
Verification burden should become a formal metric. Researchers can measure how many actions or how much time a blind user needs to determine whether the agent’s result is correct, then compare that with sighted users. An agent may have equal task success but impose much higher verification cost on blind users. That would be an accessibility gap invisible to conventional benchmarks.
Information parity is another candidate metric. Did the user receive the material distinctions necessary to make a decision? In shopping, this may include price, quantity and delivery. In travel, total cost, dates, airports and restrictions. In a file operation, source, destination and overwrite behavior. This measure captures the Morae insight that successful automation can still reduce agency.
Longitudinal studies should track adaptation. Do users become faster? Do they change confirmation settings? Do they discover new uses? Does trust become better calibrated or more complacent? Do screen-reader skills decline for tasks that are routinely automated? Do users develop efficient hybrid strategies?
Benchmarks should include adversarial situations. A webpage can contain misleading labels, visual-semantic conflicts, prompt-injection text, duplicate options and partial failures. Safety should be tested under realistic messiness, not only ideal interfaces.
Evaluation datasets should document participant diversity. Blindness onset, residual vision, screen-reader expertise, braille use, language, age and technical background may affect outcomes. Small samples are understandable in accessibility research, but transparent reporting helps readers judge generalizability.
Finally, success should include subjective experience without reducing it to satisfaction. Users can report perceived control, confidence, workload, frustration, privacy comfort and willingness to delegate similar tasks. A technically successful system that users do not trust or understand is not ready for assistive deployment.
55. A Detailed Research Agenda for the Next Generation of Assistive Agents
The field is young enough that many foundational questions remain open. The following agenda is organized around problems that directly affect real-world accessibility rather than around model benchmarks alone.
55.1 Accessible state representation
What is the best shared representation of interface state for both agents and screen readers? Can accessibility trees, DOM, screenshots and application APIs be fused into a standardized model that remains inspectable by users? How should disagreements between modalities be represented?
55.2 Nonvisual agent trajectories
How should a long sequence of agent actions be summarized for speech and braille? Which events deserve announcement? Can users switch between milestone summaries and fine-grained traces without losing context?
55.3 Decision-point detection
Can agents reliably distinguish mechanical choices from value-laden choices? How should systems determine when two options are meaningfully different for a particular user? Can preference models reduce unnecessary questions without silently narrowing choice?
55.4 Confirmation design
Which confirmation formats minimize errors while avoiding fatigue? How should confirmation differ between speech, braille and magnified visual interfaces? What information must be repeated before financial, legal or public actions?
55.5 Accessible verification
What forms of evidence allow blind users to verify outcomes efficiently? Are semantic diffs, structured receipts or before/after summaries most effective? How does verification burden compare between blind and sighted users?
55.6 Trust calibration
How do blind users learn the strengths and weaknesses of agents over time? Which uncertainty messages improve calibration without making useful systems feel unreliable? How should systems communicate model updates that may change behavior?
55.7 Braille-first agent interfaces
How should agent plans, code changes, data tables and confirmations be optimized for refreshable braille? Can tactile presentation reduce cognitive load in workflows where speech is too transient?
55.8 Low-vision collaboration
How can agents respect magnification, color preferences and partial visual scanning? Can they avoid moving content outside the user’s current magnified viewport? What handoff mechanisms work best?
55.9 Mobile agent accessibility
Smartphones are primary computing devices for many users. How should mobile agents coordinate with VoiceOver, TalkBack, gestures, camera input and app permissions? Can the agent act without disrupting the user’s screen-reader rotor or focus?
55.10 Physical-world assistance
Which multimodal tasks are safe enough for agentic action, and which should remain descriptive? How should agents express spatial uncertainty? Can real-time framing assistance improve the reliability of user-provided camera input?
55.11 Prompt-injection resilience
Do existing defenses work when malicious instructions are hidden visually or embedded in inaccessible content? How should an agent explain an attack to a blind user? Can security warnings be concise enough to avoid overwhelming speech users?
55.12 Permission comprehension
Can users accurately understand agent permissions when presented in natural language? Which abstractions—tools, data categories, actions or goals—make authorization easiest to reason about?
55.13 Memory and privacy
What accessibility preferences are useful to store long term? How can systems avoid turning preference memory into a disability profile? What interfaces allow users to inspect and edit memory efficiently?
55.14 Agent handoff
When automation stops, where should screen-reader focus go? What information should be announced? Can standardized checkpoints make it possible for users to take over without reorienting from scratch?
55.15 Failure recovery
Which undo and rollback patterns work across web, desktop and mobile environments? Can agents automatically create restore points before risky changes? How should recovery be exposed when the underlying application has no undo?
55.16 Agent-generated accessibility repair
Can user-side agents safely repair inaccessible markup without introducing regressions? Which verification loops can guarantee that semantics improve? How should temporary repairs be shared back with developers without normalizing inaccessible source products?
55.17 Accessibility testing by agents
AI can explore dynamic interfaces, but current research shows limits in semantic evaluation. How should agents combine automated rules, model reasoning and human judgment? Can they identify issues that conventional scanners miss without producing unmanageable false positives?
55.18 Learning versus delegation
When does guidance help users build transferable skills, and when is automation more appropriate? Can systems detect that a user wants to learn rather than merely finish?
55.19 Employment outcomes
Do accessible agents improve job retention, promotion, task diversity or entrepreneurship? Who receives the productivity gains? How do organizational restrictions affect disabled employees differently?
55.20 Educational equity
How should schools distinguish AI used as an accessibility accommodation from AI used to generate assessed work? What secure tools and policies can provide equal access without creating academic-integrity ambiguity?
55.21 Multilingual inclusion
How do agentic accessibility systems perform in languages underrepresented in training data? Which local datasets and partnerships are needed? How should systems handle code-switching common in multilingual communities?
55.22 Low-resource deployment
Can small on-device models provide meaningful agentic accessibility on affordable hardware? Which functions should be local, and which require cloud reasoning? How can interfaces remain useful during intermittent connectivity?
55.23 Portability and lock-in
Can accessibility preferences, permission rules and learned workflows move between agent providers? What open formats are needed so users do not lose years of personalization when changing platforms?
55.24 Disabled people as builders
How does agentic programming change who can create assistive technology? What support do nonprogrammers need to test security and reliability? Can communities maintain user-generated tools collectively?
55.25 Measuring independence
Perhaps the most important question is conceptual: what outcome should accessibility research optimize? Task speed is not enough. Independence may include privacy, choice, confidence, ability to recover, control over assistance and freedom to select tools. Developing validated measures of agent-supported digital independence would give the field a more meaningful target.
56. Toward a Rights-and-Capabilities View of Digital Independence
Accessibility discussions often alternate between rights language and productivity language. Rights emphasize equal access, nondiscrimination and participation. Productivity emphasizes efficiency and task completion. Agentic AI requires both perspectives.
A system can make a user highly productive while restricting autonomy. For example, a locked-down corporate agent might complete many tasks but prevent the user from accessing underlying information directly. Conversely, a perfectly standards-compliant interface may technically satisfy access requirements while imposing far more work on a blind user than on colleagues. Digital independence includes both entitlement to direct access and practical capability to accomplish goals.
A capabilities perspective asks what a person is actually able to do. Can they privately manage finances? Can they research a topic? Can they choose among products? Can they create and publish? Can they participate in work without constant assistance from others? Agentic AI can expand these capabilities when it absorbs mechanical barriers.
A rights perspective sets boundaries. Users should not be forced to accept AI surveillance as the price of access. They should not lose direct accessibility because a company prefers an automated intermediary. They should not be denied meaningful choices because an agent optimizes for speed. They should have recourse when automated systems make consequential errors.
The combination suggests a useful policy principle: agentic assistance should expand the set of accessible options without removing existing ones. It should add a path, not close a path. A government service that becomes easier through an agent should still work with a screen reader directly. An employer may offer AI assistance but should not withdraw conventional accommodations.
Choice among modes is itself a capability. On one day the user may want manual control. On another, fatigue or time pressure may make delegation preferable. Accessibility is strongest when the environment supports both.
57. What Professional Research and Product Claims Should Not Say
The rapid pace of AI encourages exaggerated claims. Accessibility is especially vulnerable because compelling demonstrations can be mistaken for evidence of broad real-world effectiveness. Professional research should resist several shortcuts.
First, a small user study should not be generalized to all blind people. Studies with eight, eleven, twelve or twenty participants can reveal important mechanisms and design problems, but they do not establish universal preference. Findings should be described in relation to the sample and task.
Second, benchmark success is not equivalent to accessibility. An agent that completes a task in a standard browser may fail under keyboard-only or magnified conditions, as A11y-CUA demonstrates. Benchmarks should not be presented as evidence of assistive readiness unless assistive interaction is actually evaluated.
Third, generated descriptions should not be described as “seeing for blind people” without acknowledging error. Multimodal systems can be extraordinary tools, yet empirical studies continue to find incorrect answers, abstentions and context limitations. The responsible claim is that they can expand access to visual information, not eliminate uncertainty.
Fourth, agent autonomy should not be equated with user independence. Independence depends on control, alternatives and verification. A highly autonomous agent can create dependency if the user cannot understand or override it.
Fifth, accessibility overlays or agents should not be represented as substitutes for accessible source design. AI mediation can provide immediate value while remediation proceeds, but it should not become an excuse to ignore standards.
Sixth, vendor case studies should be identified as vendor evidence. They can document capabilities and deployments but do not carry the same weight as independent controlled research. This monograph follows that distinction in its sourcing.
Finally, a professional research publication should state limitations and review status. This monograph is an independent narrative synthesis, not a systematic review or externally peer-reviewed academic article. That status does not make the analysis worthless; it tells readers how to interpret it.
58. A Practical Checklist for Accessibility-Aligned Agent Deployment
The following checklist condenses the three-part monograph into deployment questions. It is intended as a practical review instrument rather than a formal standard.
Interface foundation
- Does the underlying application remain usable with screen readers and keyboard input without the agent?
- Does the agent itself expose properly labeled controls, headings, status messages and focus behavior?
- Can braille and magnification users access the same agent state as speech users?
Perception
- Does the agent prefer semantic accessibility information over coordinate guessing?
- Can it combine DOM, accessibility tree, APIs, OCR and vision where appropriate?
- Does it detect conflicts between perception channels?
Planning and constraints
- Are user constraints represented explicitly across long workflows?
- Can the user inspect an operational plan for consequential tasks?
- Does the system distinguish mechanical steps from decisions requiring preference?
Action and permission
- Are tool permissions scoped to the task?
- Are consequential tools unavailable unless the workflow actually requires them?
- Can permissions expire automatically?
Confirmation
- Do prompts state the exact consequence rather than asking generic “Are you sure?” questions?
- Are sending, spending, deleting, publishing, signing and sensitive disclosure confirmation-gated by default?
- Can experienced users configure standing rules for routine workflows?
Verification
- Does every important action have a defined success condition?
- Does the agent verify outcomes independently when possible?
- Is verification evidence available nonvisually?
Recovery
- Can the user pause or stop through a stable global control?
- Are reversible operations preferred?
- Does handoff preserve screen-reader orientation?
Security and privacy
- Is untrusted content separated from instructions?
- Are camera, screenshot and document captures minimized?
- Can users inspect and revoke stored preferences and permissions?
Evaluation
- Has the system been tested with real blind and low-vision users?
- Does testing include braille, magnification and different expertise levels?
- Are task success, user control, verification burden and harmful failure measured separately?
Institutional governance
- Is there an approved accessibility use pathway rather than a blanket AI policy?
- Can actions be attributed to agent versus human where necessary?
- Is there a non-AI fallback for outages or provider changes?
No product will satisfy every item perfectly at the beginning. The checklist is valuable because it makes omissions visible. Accessibility-aligned agency is not a single feature; it is a system property.
59. Final Synthesis: The Accessible Agent as a New Kind of Assistive Technology
The history of digital accessibility can be read as a series of abstraction layers. Braille transformed written language into tactile symbols. Screen readers transformed programmatic interfaces into speech and braille. Optical character recognition transformed images of text into machine-readable text. Generative AI transforms heterogeneous content into language. Agentic AI may transform goals into sequences of action.
Each abstraction creates power by hiding lower-level complexity. Each also creates dependency on the layer doing the translation. The lesson from accessibility history is not to reject abstraction, but to make it inspectable, interoperable and controlled by the user.
Agentic AI is particularly promising because it attacks a stubborn problem: the extra labor required to navigate systems designed for visual interaction. It can search rather than make the user traverse, compare rather than make the user inspect every card, manipulate inaccessible controls, organize scattered information and bridge across applications. It can also describe visual state, build custom tools and provide context-sensitive instruction.
But an agent that acts invisibly is not accessible merely because it produces the right outcome. Blind users need the same opportunity to understand and influence the process that sighted users receive by watching the screen. That requires accessible trajectory state, choice preservation, verification, interruption and recovery.
The evidence reviewed across this monograph consistently points toward mixed initiative rather than maximal autonomy. Savant shows the efficiency of natural-language control. AskEase shows the value of contextual guidance. Morae shows why agents should pause for meaningful choices. A11y-CUA shows that mainstream computer-use agents do not automatically fit assistive-technology workflows. OLLA shows that accessible agents can support real desktop use while still encountering substantial failure. Multimodal studies show meaningful access gains alongside persistent error. NIST and risk-management guidance show why permissions, monitoring and intervention must surround powerful tool use.
These findings are not arguments against deployment. They are design instructions. Use agents where they remove friction. Build native accessibility beneath them. Scope permissions. Verify outcomes. Ask at commitment boundaries. Preserve direct screen-reader access. Make uncertainty explicit. Let users choose how much autonomy they want.
For developers, the central technical opportunity is to treat accessibility semantics as agent infrastructure. Roles, names, states and actions provide a stable machine-readable interface that benefits people and automation simultaneously. For researchers, the opportunity is to define evaluation around human control and verification burden rather than task success alone. For institutions, the opportunity is to provide secure agentic accommodations without turning AI into a new gatekeeper. For users, the opportunity is to shift from adapting themselves to every interface toward making interfaces adapt to their goals.
The phrase “agentic accessibility” should therefore mean more than adding an AI button to an inaccessible product. It should describe a computing architecture in which agents are designed from the beginning to work with assistive technology, expose their actions, respect user preferences, operate within permission boundaries and preserve human authority.
If that architecture develops, the distinction between “assistive technology” and “mainstream productivity technology” may become less rigid. An agent that summarizes an interface for a blind user can also help a sighted user navigate a complex enterprise system. A verification log designed for nonvisual oversight can improve accountability for everyone. A permission model designed to protect an assistive agent can improve agent security generally. Disability-centered design can once again serve as a source of broader computing innovation.
The ultimate objective is not to make blind people use computers more like sighted people. It is to make computers responsive to human intention through whatever modality the person chooses. Screen readers accomplished this by freeing text and controls from the visual display. Agentic AI can extend the same principle from perception to action.
That possibility justifies serious investment and serious caution. The technology is useful now. It is imperfect now. Both statements can be true. The path forward is not hype or rejection, but disciplined development around evidence, direct accessibility and user control.
Digital independence in the agentic era should mean this: the person can understand the environment, choose the goal, decide what to delegate, know what the machine did, verify what matters, reverse what can be reversed, and take control whenever they wish. When an agent meets that standard, automation becomes not a substitute for accessibility, but one of its most powerful extensions.