pith. sign in

arxiv: 2605.19638 · v1 · pith:NPC24OQHnew · submitted 2026-05-19 · 💻 cs.HC · cs.AI· cs.CY· cs.SE

The Accessibility Capability Boundary: Operational Limits and Expansion Potential of AI-Generated Browser-Native Accessibility Systems

Rizwan Jahangir , Daisuke Ishii This is my paper

Pith reviewed 2026-05-20 04:22 UTC · model grok-4.3

classification 💻 cs.HC cs.AIcs.CYcs.SE
keywords accessibility computingAI-generated interfacesbrowser-native systemsaccessibility capability boundaryLLM user interfacesvisual impairment toolsdeployment latencycontext-specific adaptation
0
0 comments X

The pith

AI-generated single-file browser interfaces can shift the accessibility capability boundary outward by slashing deployment friction.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper proposes the Accessibility Capability Boundary as a way to think about the limits of AI in creating accessible systems. It claims that by using large language models to generate single-file HTML tools that run in any browser, these systems can reach more users because they need no installation or special setup. The authors support this with two prototypes: one helping a blind person in Nepal and another guiding visually impaired users with a webcam. If correct, this means accessibility features could be created and shared much faster and more cheaply than traditional methods. Readers interested in technology for disability support would see potential for more personalized and immediate solutions.

Core claim

The paper defines the Accessibility Capability Boundary as a formal framework modeling accessibility as a dynamic multidimensional capability space limited by deployment latency, cognitive load, infrastructure dependency, offline persistence, interaction complexity, and adaptability. It proposes that AI-generated browser-native systems as single-file HTML artifacts using standard browser APIs can expand this boundary by achieving near-zero deployment friction and enabling rapid context-specific adaptations, as shown through analysis of two exploratory prototypes including a browser-native interface for a blind user and a webcam alignment assistant for visually impaired users.

What carries the argument

The Accessibility Capability Boundary (ACB), a formal framework that treats accessibility as a capability space defined by measurable constraints, which is used to identify reachable and unreachable regions for AI-generated systems.

If this is right

  • These systems can reduce deployment latency to near zero.
  • Context-specific interface adaptation becomes possible without expert intervention.
  • Dependency on external infrastructure is minimized.
  • Offline use and persistence are supported through browser standards.
  • New regions of interaction complexity become accessible for users with disabilities.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • This paradigm might enable accessibility solutions tailored to individual cultural or environmental contexts beyond the prototypes shown.
  • Integration with emerging web standards could further reduce cognitive load for end users.
  • Future verification methods for AI-generated accessibility might address current hard boundaries in complex scenarios.
  • Broader adoption could shift focus from compliance checklists to capability expansion in accessibility research.

Load-bearing premise

The two exploratory prototypes sufficiently represent the general expansion potential of AI-generated browser-native accessibility systems across varied users, contexts, and complexities.

What would settle it

Demonstrating a scenario where an AI-generated single-file HTML accessibility system requires significant additional setup time or external resources for a new user group with complex interaction needs would indicate that the boundary expansion is more limited than proposed.

Figures

Figures reproduced from arXiv: 2605.19638 by Daisuke Ishii, Rizwan Jahangir.

Figure 1
Figure 1. Figure 1: Conceptual Accessibility Frontier illustrating operational regions for three system classes in [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Architecture of an AI-generated browser-native accessibility system. An LLM synthesizes a [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Closed-Loop Accessibility Interaction Pipeline. MediaPipe FaceMesh extracts facial landmarks [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: The browser-native interface during active tracking. The UI relies on ARIA-labeled semantic [PITH_FULL_IMAGE:figures/full_fig_p014_4.png] view at source ↗
read the original abstract

As large language models (LLMs) demonstrate increasing competence in synthesizing functional user interfaces, a fundamental question emerges in accessibility computing: \textit{how far can AI-driven accessibility systems go?} This paper introduces the \textit{Accessibility Capability Boundary} (ACB), a formal framework for reasoning about the operational limits and expansion potential of autonomous accessibility systems, and grounds this theory in a real-world systems artifact. We model accessibility not as a binary compliance property but as a dynamic, multidimensional capability space constrained by measurable variables including deployment latency, cognitive load, infrastructure dependency, offline persistence, interaction complexity, and adaptability. We argue that AI-generated, browser-native systems constructed as single-file HTML artifacts leveraging standard browser APIs may dramatically shift the ACB outward by reducing deployment friction to near-zero and enabling rapid, context-specific interface adaptation. We ground our theoretical framework in the analysis of two real-world exploratory prototypes. The first is an AI-generated browser-native accessibility interface deployed for a blind user in Nepal. The second is a fully functional, open-source webcam alignment assistant for visually impaired users, serving as a concrete systems artifact. Through formal definitions, propositions, and a comparative evaluation matrix, we characterize the regions of the accessibility capability space that such systems can and cannot reach. We further identify remaining computational, infrastructural, and verification constraints that constitute the hard boundaries of this paradigm. This work contributes a theoretical foundation for understanding the scalable limits of autonomous accessibility computing and proposes a research agenda for future work in accessibility-aware AI systems.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper introduces the Accessibility Capability Boundary (ACB), a formal framework for reasoning about the operational limits and expansion potential of autonomous accessibility systems. Accessibility is modeled as a dynamic, multidimensional capability space constrained by variables including deployment latency, cognitive load, infrastructure dependency, offline persistence, interaction complexity, and adaptability. The central claim is that AI-generated, browser-native systems constructed as single-file HTML artifacts leveraging standard browser APIs may dramatically shift the ACB outward by reducing deployment friction to near-zero and enabling rapid, context-specific interface adaptation. This is grounded in formal definitions, propositions, a comparative evaluation matrix, and analysis of two real-world exploratory prototypes: an AI-generated browser-native accessibility interface for a blind user in Nepal and a fully functional open-source webcam alignment assistant for visually impaired users. Remaining computational, infrastructural, and verification constraints are identified as hard boundaries.

Significance. If the central claims hold, the work supplies a theoretical foundation for understanding the scalable limits of autonomous accessibility computing and outlines a research agenda for accessibility-aware AI systems. The grounding in concrete, real-world prototypes and the shift from binary compliance to a measurable capability space represent clear strengths. The formal modeling and identification of hard boundaries could usefully inform future systems work in human-computer interaction and accessibility.

major comments (2)
  1. [Grounding section and propositions] Grounding section and propositions: The claim that the two exploratory prototypes are representative of the general expansion potential of the paradigm across diverse users, contexts, and interaction complexities is load-bearing for the central assertion that single-file HTML browser-native AI systems can dramatically shift the ACB outward. The manuscript provides no scaling analysis, explicit mapping of the prototypes onto the multidimensional space, or counter-example analysis to support this extrapolation.
  2. [Comparative evaluation matrix] Comparative evaluation matrix: The matrix is described as characterizing reachable and unreachable regions of the capability space, yet the manuscript supplies no quantitative data, error bounds, or sensitivity analysis on the listed constraint variables (deployment latency, cognitive load, etc.). This weakens verification of the propositions about what the paradigm can and cannot reach.
minor comments (2)
  1. [Introduction] The abstract and introduction introduce several constraint variables without a consolidated table or diagram that would clarify their relationships and measurement.
  2. [Formal definitions] Notation for the ACB and its boundary regions could be made more explicit (e.g., by defining a formal tuple or coordinate system) to aid readers in following the propositions.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive review and for identifying areas where the grounding and evaluation could be strengthened. We address each major comment below and describe the revisions we will incorporate.

read point-by-point responses

  1. Referee: [Grounding section and propositions] Grounding section and propositions: The claim that the two exploratory prototypes are representative of the general expansion potential of the paradigm across diverse users, contexts, and interaction complexities is load-bearing for the central assertion that single-file HTML browser-native AI systems can dramatically shift the ACB outward. The manuscript provides no scaling analysis, explicit mapping of the prototypes onto the multidimensional space, or counter-example analysis to support this extrapolation.

    Authors: We agree that the two prototypes are exploratory demonstrations rather than a comprehensive scaling study, and that stronger grounding is needed to support claims about outward shifts in the ACB. In revision we will add an explicit mapping of each prototype onto the six ACB dimensions, showing measured or observed values for deployment latency, cognitive load, infrastructure dependency, offline persistence, interaction complexity, and adaptability. We will also insert a dedicated limitations subsection that discusses extrapolation risks and provides counter-example scenarios (for instance, real-time collaborative editing or high-stakes medical interfaces that exceed single-file browser constraints). These additions will clarify that the prototypes illustrate reachable regions rather than prove generalizability across all contexts. revision: yes

  2. Referee: [Comparative evaluation matrix] Comparative evaluation matrix: The matrix is described as characterizing reachable and unreachable regions of the capability space, yet the manuscript supplies no quantitative data, error bounds, or sensitivity analysis on the listed constraint variables (deployment latency, cognitive load, etc.). This weakens verification of the propositions about what the paradigm can and cannot reach.

    Authors: The matrix is currently qualitative, derived from the observed behavior of the two deployed prototypes. We will revise the matrix to include the quantitative measurements that were collected during the Nepal deployment and the webcam-assistant development (e.g., observed deployment latency in seconds, qualitative cognitive-load ratings from user interviews). Where statistical error bounds are unavailable because the work is exploratory rather than a controlled experiment, we will label the entries as point estimates and add a short sensitivity discussion based on the range of infrastructure conditions encountered. This will make the characterization of reachable versus unreachable regions more verifiable while preserving the exploratory framing. revision: partial

Circularity Check

0 steps flagged

No significant circularity detected in framework derivation

full rationale

The paper defines the Accessibility Capability Boundary as an independent formal framework using a set of measurable variables (deployment latency, cognitive load, infrastructure dependency, offline persistence, interaction complexity, adaptability). It then advances a theoretical argument that AI-generated browser-native single-file HTML systems can expand the reachable region of this space, and illustrates the argument via analysis of two exploratory prototypes. No proposition, prediction, or central claim reduces by construction to a fitted parameter, self-referential definition, or self-citation chain; the prototypes function as grounding examples rather than inputs that define the framework itself. The derivation therefore remains self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The paper rests on the modeling choice that accessibility is best captured by the six listed variables and that browser APIs plus AI generation suffice to expand the space; no numerical free parameters are mentioned.

axioms (1)
  • domain assumption Accessibility is modeled as a dynamic, multidimensional capability space constrained by deployment latency, cognitive load, infrastructure dependency, offline persistence, interaction complexity, and adaptability.
    This modeling premise is stated directly in the abstract as the basis for the ACB framework.
invented entities (1)
  • Accessibility Capability Boundary (ACB) no independent evidence
    purpose: Formal framework for reasoning about operational limits and expansion potential of autonomous accessibility systems.
    New construct introduced by the paper; no independent evidence or external validation is provided in the abstract.

pith-pipeline@v0.9.0 · 5815 in / 1398 out tokens · 47020 ms · 2026-05-20T04:22:27.233569+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

37 extracted references · 37 canonical work pages

  1. [1]

    Web Content Accessibility Guidelines (WCAG) 2.0

    Ben Caldwell, Michael Cooper, Loretta Guarino Reid, and Gregg Vanderheiden. Web Content Accessibility Guidelines (WCAG) 2.0. W3c recommendation, World Wide Web Consortium (W3C), 2008

    work page 2008

  2. [2]

    Accessible Rich Internet Applications (WAI-ARIA) 1.2

    Joanmarie Diggs, James Nurthen, Richard Schwerdtfeger, et al. Accessible Rich Internet Applications (WAI-ARIA) 1.2. W3c recommendation, World Wide Web Consortium (W3C), 2023

    work page 2023

  3. [3]

    Physical accessibility of touchscreen smartphones

    Shari Trewin, Cal Swart, and Daniel Pettick. Physical accessibility of touchscreen smartphones. In Proceedings of the 15th International ACM SIGACCESS Conference on Computers and Accessibility (ASSETS ’13). ACM, 2013

    work page 2013

  4. [4]

    Apress, New York, 2007

    Jonathan Lazar et al.Web Accessibility: Web Standards and Regulatory Compliance. Apress, New York, 2007

    work page 2007

  5. [5]

    Bigham, Chandrika Jayant, Hanjie Ji, Greg Little, Andrew Miller, Robert C

    Jeffrey P. Bigham, Chandrika Jayant, Hanjie Ji, Greg Little, Andrew Miller, Robert C. Miller, Robin Miller, Aubrey Tatarowicz, Brandyn White, Samuel White, and Tom Yeh. Crowdsourcing accessibility: Human-powered access technologies. InProceedings of the 13th International ACM SIGACCESS Conference on Computers and Accessibility (ASSETS ’11). ACM, 2011

    work page 2011

  6. [6]

    A survey on large language models for code generation.ACM Transactions on Software Engineering and Methodology, 34(2):1–44, 2025

    Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. A survey on large language models for code generation.ACM Transactions on Software Engineering and Methodology, 34(2):1–44, 2025

    work page 2025

  7. [7]

    Leveraging large language models for end-user website generation

    Tommaso Cal` o and Luigi De Russis. Leveraging large language models for end-user website generation. InInternational Symposium on End User Development (IS-EUD 2023), pages 55–70. Springer, 2023

    work page 2023

  8. [8]

    An accessibility infrastructure for the global south

    Joyojeet Pal et al. An accessibility infrastructure for the global south. InProceedings of the 2016 CHI Conference Extended Abstracts on Human Factors in Computing Systems. ACM, 2016

    work page 2016

  9. [9]

    Access to assistive technology for persons with disabilities: A critical review from nepal, india and bangladesh.Disability and Rehabilitation: Assistive Technology, 2023

    Jyoti Karki et al. Access to assistive technology for persons with disabilities: A critical review from nepal, india and bangladesh.Disability and Rehabilitation: Assistive Technology, 2023

    work page 2023

  10. [10]

    Web Content Accessibility Guidelines (WCAG) 2.2

    W3C Web Accessibility Initiative. Web Content Accessibility Guidelines (WCAG) 2.2. W3c recom- mendation, World Wide Web Consortium (W3C), 2023

    work page 2023

  11. [11]

    Research Report on Web Accessibility Metrics

    W3C Web Accessibility Initiative. Research Report on Web Accessibility Metrics. W3c working group note, World Wide Web Consortium (W3C), 2012

    work page 2012

  12. [12]

    Metric for web accessibility evaluation

    Markel Vigo, Justin Brown, and Vivienne Conway. Metric for web accessibility evaluation. In Proceedings of the 8th International Cross-Disciplinary Conference on Web Accessibility (W4A ’11). ACM, 2011

    work page 2011

  13. [13]

    Wobbrock, Shaun K

    Jacob O. Wobbrock, Shaun K. Kane, Krzysztof Z. Gajos, Susumu Harada, and Jon Froehlich. Ability-based design: Concept, principles and examples.ACM Transactions on Accessible Computing (TACCESS), 3(3):9:1–9:27, 2011. 19

    work page 2011

  14. [14]

    Hans Persson, Henrik ˚Ahman, Alexander Arvei Yngling, and Jan Gulliksen. Universal design, inclusive design, accessible design, design for all: Different concepts—one goal? on the concept of accessibility— historical, methodological and philosophical aspects.Universal Access in the Information Society, 14(4):505–526, 2015

    work page 2015

  15. [15]

    Andrew Sears and Vicki L. Hanson. Representing users in accessibility research. InProceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI ’11). ACM, 2011

    work page 2011

  16. [16]

    Muniz, Kiev Gama, Lincoln Rocha, and Windson Viana

    Daniel Mesquita Feij´ o Rabelo, Jo˜ ao H. Muniz, Kiev Gama, Lincoln Rocha, and Windson Viana. Breaking barriers in mobile accessibility: A study of llm-generated native android interfaces. In Proceedings of the IEEE/ACM International Conference on Mobile Software Engineering and Systems (MOBILESoft). IEEE, 2025

    work page 2025

  17. [17]

    Can generative ai create accessible web code? a benchmark analysis of ai-generated html against accessibility standards.Universal Access in the Information Society, 2025

    Iyad Abu Doush and Rami Kassem. Can generative ai create accessible web code? a benchmark analysis of ai-generated html against accessibility standards.Universal Access in the Information Society, 2025

    work page 2025

  18. [18]

    On the interaction with large language models for web accessibility: Implications and challenges

    Giovanni Delnevo, Manuel Andruccioli, and Silvia Mirri. On the interaction with large language models for web accessibility: Implications and challenges. In2024 IEEE 21st Consumer Communications & Networking Conference (CCNC). IEEE, 2024

    work page 2024

  19. [19]

    O’Reilly Media, Sebastopol, CA, 2017

    Tal Ater.Building Progressive Web Apps: Bringing the Power of Native to the Browser. O’Reilly Media, Sebastopol, CA, 2017

    work page 2017

  20. [20]

    Evaluating progressive web app accessibility for people with disabilities

    Yolanda Quispe-Quispe et al. Evaluating progressive web app accessibility for people with disabilities. Computers, 2(2), 2022

    work page 2022

  21. [21]

    Implementing an offline-first web application

    Vladyslav Malanin. Implementing an offline-first web application. Master’s Thesis, Aalto University, 2019

    work page 2019

  22. [22]

    Multimodal navigation systems for users with visual impairments.Multimodal Technologies and Interaction, 4(4):73, 2020

    Bineeth Kuriakose, Rajesh Shrestha, and Frode Eika Sandnes. Multimodal navigation systems for users with visual impairments.Multimodal Technologies and Interaction, 4(4):73, 2020

    work page 2020

  23. [23]

    Multimodal user interfaces to improve social integration of persons with disabilities.Disability and Rehabilitation: Assistive Technology, 8(4):301–309, 2012

    Miguel Sales Dias et al. Multimodal user interfaces to improve social integration of persons with disabilities.Disability and Rehabilitation: Assistive Technology, 8(4):301–309, 2012

    work page 2012

  24. [24]

    Toward a computer vision-based wayfinding aid for blind persons to access unfamiliar indoor environments.Machine Vision and Applications, 23(6):1173–1186, 2012

    Roberto Manduchi and Sri Kurniawan. Toward a computer vision-based wayfinding aid for blind persons to access unfamiliar indoor environments.Machine Vision and Applications, 23(6):1173–1186, 2012

    work page 2012

  25. [25]

    Bigham, Chandrika Jayant, Hanjie Ji, Greg Little, Andrew Miller, Robert C

    Jeffrey P. Bigham, Chandrika Jayant, Hanjie Ji, Greg Little, Andrew Miller, Robert C. Miller, Robin Miller, Aubrey Tatarowicz, Brandyn White, Samuel White, and Tom Yeh. Vizwiz: Nearly real-time answers to visual questions. InProceedings of the 23nd Annual ACM Symposium on User Interface Software and Technology (UIST ’10). ACM, 2010

    work page 2010

  26. [26]

    Core Accessibility API Mappings 1.2

    W3C Accessibility Guidelines Working Group. Core Accessibility API Mappings 1.2. W3c recommen- dation, World Wide Web Consortium (W3C), 2023

    work page 2023

  27. [27]

    Web Speech API

    W3C Community Group. Web Speech API. W3C Community Group Report, 2023

    work page 2023

  28. [28]

    MediaDevices.getUserMedia() – Web APIs

    MDN Web Docs. MediaDevices.getUserMedia() – Web APIs. Mozilla Developer Network, 2024

    work page 2024

  29. [29]

    Information & communication technology for the social inclusion of persons with disabilities in developing country: Special reference to nepal

    Kamal Lamichhane. Information & communication technology for the social inclusion of persons with disabilities in developing country: Special reference to nepal. InProceedings of the 1st ACM Symposium on Computing for Development (ACM DEV ’10). ACM, 2010. 20

    work page 2010

  30. [30]

    axe-core: Accessibility engine for automated Web UI testing

    Deque Systems. axe-core: Accessibility engine for automated Web UI testing. https://github.com/ dequelabs/axe-core, 2023

    work page 2023

  31. [31]

    WAVE Web Accessibility Evaluation Tools.https://wave.webaim.org/, 2024

    WebAIM. WAVE Web Accessibility Evaluation Tools.https://wave.webaim.org/, 2024

    work page 2024

  32. [32]

    Lighthouse Accessibility Audits

    Google Chrome Developers. Lighthouse Accessibility Audits. https://developer.chrome.com/ docs/lighthouse/accessibility/, 2023

    work page 2023

  33. [33]

    Using the NVDA Screen Reader to Test Web Accessibility

    WebAIM. Using the NVDA Screen Reader to Test Web Accessibility. https://webaim.org/ articles/nvda/, 2024

    work page 2024

  34. [34]

    SUS-A Quick and Dirty Usability Scale

    John Brooke. SUS-A Quick and Dirty Usability Scale. InUsability Evaluation in Industry, pages 189–194. Taylor & Francis, 1996

    work page 1996

  35. [35]

    Hart and Lowell E

    Sandra G. Hart and Lowell E. Staveland. Development of NASA-TLX (Task Load Index): Results of Empirical and Theoretical Research.Advances in Psychology, 52:139–183, 1988

    work page 1988

  36. [36]

    Mediapipe face mesh

    Google. Mediapipe face mesh. https://google.github.io/mediapipe/solutions/face_mesh. html, 2020

    work page 2020

  37. [37]

    Benchmarking web accessibility evaluation tools: measuring the harm of sole reliance on automated tests

    Markel Vigo, Justin Brown, and Vivienne Conway. Benchmarking web accessibility evaluation tools: measuring the harm of sole reliance on automated tests. InProceedings of the 10th International Cross-Disciplinary Conference on Web Accessibility (W4A ’13). ACM, 2013. 21

    work page 2013