A11YRepair: Bridging Web Accessibility Barriers via Knowledge-Enhanced Divide-and-Conquer Repair

Unknown

Conceptio › Archive › arXiv CS

arXiv CSopen access

A11YRepair: Bridging Web Accessibility Barriers via Knowledge-Enhanced Divide-and-Conquer Repair

Unknown · 2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

Open Source ↗Direct PDF ↓

softwarearchitecture softwareengineering testing

software engineering, software architecture, testing

arXiv:2606.21926v1 [cs.SE] 20 Jun 2026

A11YRepair: Bridging Web Accessibility Barriers via Knowledge-Enhanced Divide-and-Conquer Repair Kai Huang

Ling Zhu

Jian Zhang

[email protected] Technical University of Munich Germany

[email protected] Nanyang Technological University Singapore

Xiaofei Xie

Chunyang Chen

[email protected] Singapore Management University Singapore

[email protected] Technical University of Munich Germany

Abstract Web accessibility (A11Y), which ensures web content is perceivable and usable for users with disabilities, is a critical requirement for modern web applications. Yet existing tooling overwhelmingly focuses on detecting A11Y violations rather than repairing them. Automated program repair (APR) techniques appear promising for this setting, but our study shows that state-of-the-art APR systems perform poorly when applied to real-world A11Y violations. Unlike conventional sparse-bug scenarios, web A11Y issues often manifest as multiple structurally related violations per page, requiring coordinated edits across multiple files. Existing repair systems fail to manage this multi-fault scale, as they handle each bug individually without considering their relationships or incorporating domain rules such as the Web Content Accessibility Guidelines (WCAG). We propose A11YRepair, an LLM-based framework designed specifically for web A11Y repair. A11YRepair introduces a divideand-conquer workflow that first clusters violations requiring coordinated edits to reduce redundant localization, and then decomposes each cluster by root cause so the LLM can generate focused and consistent patches. The framework further incorporates WCAGdriven knowledge to strengthen domain awareness during both fault localization and patch synthesis. To support systematic evaluation, we construct A11YBench, a benchmark of 60 real-world web projects collected from GitHub. Experimental results show that A11YRepair achieves higher repair effectiveness and lower cost than state-of-the-art baselines, and ablation studies confirm the importance of its divide-and-conquer design and selective domain knowledge integration. Specifically, patches generated by A11YRepair have been merged into opensource projects from Google, Microsoft, Facebook, IBM, K8s, Docker, and Alibaba, demonstrating its practical value in real-world dev scenarios.

CCS Concepts • Software and its engineering → Software testing and debugging; • Human-centered computing → Accessibility technologies.

Keywords Automated Program Repair, Web Accessibility, Large Language Model, Software Usability

Figure 1: Multiple accessibility violations detected on the Ant Design homepage by using the IBM Accessibility Checker. The numbered boxes highlight different violations: ❶ Missing accessible name for SVG element; ❷ Insufficient contrast (1.42:1 for 12px text); ❸ Unlabeled combobox with invalid ARIA role; ❹❺❻ Button elements with ignored descendant img roles; ❼ Content outside landmark regions; ❽❾❿ Insufficient contrast (3.35:1 for 14px text).

Introduction

The Web has become an essential part of everyday life, yet accessibility (A11Y) remains one of its most persistent challenges. Despite decades of progress and widely adopted standards such as the Web Content Accessibility Guidelines (WCAG) [61], recent audits still find that more than 94% of high-traffic websites contain accessibility violations [64]. These issues not only hinder millions of users with disabilities from fully participating online but also impose growing compliance and maintenance costs on developers and organizations [8, 23, 27, 54]. As illustrated in Figure 1, even Ant Design [14], a popular UI framework on GitHub with 97k+ stars and maintained by Ant Group’s development team, exhibits numerous accessibility violations on its official homepage [15]. These violations span multiple WCAG criteria and create real barriers for users with disabilities: low contrast text makes content unreadable for people with moderately low vision, missing landmarks prevent efficient navigation and skipping of repeated content, unlabeled img elements remain invisible to screen readers, and improper ARIA roles can cause duplicate announcements that confuse assistive technology users. This example underscores a troubling reality: accessibility is often overlooked even in high-profile, professionally maintained projects, and multiple diverse violations commonly co-occur on a single page. Existing accessibility checkers, such as IBM’s Accessibility Checker and Deque’s axe-core [30, 53], have improved detection,

Huang et al.

but they stop short of automated repair. Developers must still interpret WCAG rules manually, making remediation time-consuming, inconsistent, and error-prone, especially as modern web pages may include dozens of interdependent elements with accessibility flaws. Recent research has called for a shift from detection to intervention [20], arguing that identifying violations alone is insufficient to achieve real accessibility. While large language models (LLMs) have advanced automated program repair (APR) [63, 72, 81], their ability to repair web accessibility violations remains largely unexplored. This gap arises because accessibility issues differ fundamentally from traditional bug scenarios: they are highly clustered [64], visually grounded [82], and governed by domain-specific standards [23]. For example, WCAG [61] defines 86 Success Criteria (Requirements) and 595 Techniques [57] for ensuring web accessibility. To investigate this, we conduct a preliminary study of repair agents for web A11Y repair. Specifically, we design and compare three repair strategies that vary in how they handle violation reports (e.g., jointly vs. individually) and incorporate domain knowledge. Our analysis reveals three key challenges. ❶ When repair agents process entire violation reports at once, they struggle to plan and coordinate across multiple violations, leading to incomplete or incoherent patches. ❷ When handling each violation separately, they achieve higher precision but suffer from excessive repetition, side effects, and inflated cost. ❸ Although WCAG knowledge is crucial for complex violations, indiscriminate retrieval often wastes context and introduces noise. These observations motivate the need for a repair framework that balances task granularity, captures violation relationships, and selectively integrates domain knowledge. Building on these observations, we identify several key design requirements for web accessibility repair. ❶ Repair frameworks must adapt task granularity to the multi-fault nature of web pages, enabling structured planning while avoiding both holistic overload and redundant per-violation repairs. ❷ Repair systems need to model cross-violation and component-level relationships to prevent duplicated effort and unintended side effects. ❸ Domain knowledge such as WCAG guidelines should be integrated selectively, providing precise guidance for complex, standards-sensitive violations without unnecessarily increasing context overhead for simple cases. Together, these requirements motivate a new repair paradigm that aligns LLM-based automation with the practical and structural characteristics of real-world web accessibility engineering. Guided by these insights, we propose A11YRepair, an LLMbased framework for automated repair of web accessibility violations. A11YRepair adopts a goal-oriented divide-and-conquer strategy that explicitly adapts task granularity by grouping multiple related violations, rather than repairing each violation in isolation. Violations are grouped based on component structure, code locality, and WCAG criteria, enabling the framework to synthesize coordinated repairs for multiple related violations within the same code region. This design prevents redundant localization and mitigates side effects that commonly arise from individually generated patches. To support accurate fault identification, A11YRepair’s fault localization module integrates DOM-structure retrieval with visual context analysis to pinpoint fault-relevant files and components. Its patch generation loop then produces minimal, root-cause–aware edits that are jointly applied to grouped violations and iteratively validated through re-checking. In addition, A11YRepair employs a

selective WCAG-driven reasoning mechanism that retrieves guideline content only when violations require quantitative thresholds or semantic interpretation, avoiding unnecessary context overhead for simple cases. Together, these designs enable A11YRepair to reason globally while acting locally, achieving an effective balance between repair precision, cost efficiency, and standards compliance. We evaluate A11YRepair on A11YBench, a benchmark of 60 real-world GitHub web projects with 8,886 violations. A11YRepair resolves 76.8% of violations at an average cost of $0.018 per issue, outperforming strong baselines such as GUIRepair in both effectiveness and cost. Notably, patches generated by A11YRepair have been merged by open-source projects from Google, Microsoft, Facebook, IBM, etc. In summary, we make the following contributions: • We built A11YBench, the first repo-level benchmark for web accessibility repair, comprising 60 real-world GitHub web projects. • We propose A11YRepair, the first LLM-based source-level web accessibility violation repair framework that combines divideand-conquer grouping and selective WCAG-guided reasoning. • We show that A11YRepair achieves SOTA performance and practical value, and we release artifacts to support future research [2].

Benchmark Construction

We construct A11YBench by collecting real-world GitHub repositories that implement production web applications using JavaScript or TypeScript. Detailed construction procedures and collected projects are documented on [1]. Overall, A11YBench consists of 60 web projects, encompassing 147 web pages and 8,886 accessibility violations spanning 45 distinct violation types, as detected by the IBM Accessibility Checker. The projects vary substantially in size, from 123 to 43,198 source files and from 3,610 to 1,555,532 lines of code, covering both lightweight documentation sites and large productiongrade applications. This scale ensures that A11YBench reflects the structural and technical diversity of modern web ecosystems. Similar to SWE-bench [33], we divide A11YBench into two sets: Lite and Full, to balance evaluation cost. A11YBench-Lite includes 10 randomly selected repositories for quick testing, A11YBench-Full comprises all 60 repositories for comprehensive evaluation. This design enables flexible benchmarking across lightweight and largescale settings [33].

Motivating Study

To understand the limitations of existing repair tools in real-world web scenarios, we conduct a lightweight motivating study to identify key challenges that motivate the design of A11YRepair.

3.1

Study Setup

3.1.1 Repair Workflow. We design three input configurations to investigate existing repair systems in the web accessibility scenario: • Basic Repair Strategy. The system receives an entire A11Y report at once, containing multiple violations. This strategy evaluates the agent’s ability to plan autonomously and coordinate multiple violations within a single context. • Iterative Repair Strategy. The system processes each violation instance individually, allowing focused reasoning on individual issues by decomposing the overall complex problem space into simpler, isolated repair sub-tasks directly. • WCAG Guided Repair Strategy. This variant extends the Iterative Repair Strategy by incorporating relevant WCAG guidelines for each violation instance, enabling us to assess the impact of domain knowledge on repair effectiveness.

A11YRepair: Bridging Web Accessibility Barriers via Knowledge-Enhanced Divide-and-Conquer Repair

Table 1: Basic and Iterative Repair Strategy. Basic Repair Strategy Systems 𝑅solve 𝑁 side 𝐶 total SWE-agent𝐵 OpenHands𝐵 GUIRepair𝐵

12.40% 17.09% 31.52%

0 1 5

$31.62 $22.60 $1.25

Iterative Repair Strategy Systems 𝑅solve 𝑁 side 𝐶 total SWE-agent𝐼 OpenHands𝐼 GUIRepair𝐼

58.97% 61.53% 72.65%

13 28 41

$173.22 $64.86 $18.87

3.1.2 Systems and Metrics. Given that existing web A11Y repair tools [16, 24, 45] cannot apply fixes at the repo-level source code, we select 3 general LLM-based repair systems: SWE-agent [72], OpenHands [52], and GUIRepair [26]. They represent the top-performing repair systems in the multimodal issue repair [55]. In the evaluation metrics, we report Violation Solve Rate (𝑅solve ), Side Effect Count (𝑁 side ), and Token Usage Cost (𝐶 total ), as defined in Section 5.3. 3.1.3 Task Instances Selection. We randomly select 5 repos from A11YBench: algorithms, carbon-design, tailwindcss, lynx, electron. To balance the cost, 20 webpages are retained randomly, containing 250 violations spanning 22 distinct WCAG 2.2 Success Criteria.

3.2

Figure 3a shows three SVG elements that lack textual alternatives, pre3 Violations: The SVG element has no accessible name venting screen reader users from understanding their (a) Fix before: 3 detected Vio. ❶ ❷ ❸. navigation purposes. As src/components/svg-icon/index.tsx shown in Figure 3b, the @@ -5,6 +5,7 @@ export const Discord = () => ( developer can resolve all xmlns="http://www.w3.org/2000/svg" three violations by ap> + <title>Discord Community Server</title> plying the same repair <g> behavior—adding descrip@@ -20,6 +21,7 @@ export const Github = () => ( xmlns="http://www.w3.org/2000/svg" tive text to a shared com> + <title>View Github Repository</title> ponent file in a single re<g> pair action. These viola@@ -31,6 +33,7 @@ export const Twitter = () => ( xmlns="http://www.w3.org/2000/svg" tions share the same root > + <title>Follow us on Twitter</title> cause and repair pattern, <g> meaning they can be repaired centrally. However, (b) Patch of 3 same repair pattern. under the iterative repair Figure 3: A motivating example of strategy, the LLM repairs each violation individucentrally repairable violations. ally, repeatedly localizing the same component and synthesizing identical patches, which leads to redundant queries and unnecessary overhead in practice. Side effects from ignoring inter-component dependencies. Figure 4a further shows 1 2 that repairing the violations in Figure 3a individ2 Violations: Accessible name does not match visible label text ually introduces two violations ❶ ❷ caused by (a) Fix after: 2 new introduced Vio. ❶ ❷. inconsistent names [31]. As shown in Figure 4b, <a href="..." aria-label="Github"> <svg xmlns="http://www.w3.org/2000/svg" ...> this occurs when speech<title>View Github Repository</title> </svg> input users navigate by </a> speaking the visible text, (b) Rendered DOM code of element ❶. a point of failure occurs when the visible label and src/components/svg-icon/index.tsx the accessible name are @@ -5,6 +5,7 @@ export const Discord = () => ( different. By analyzing xmlns="http://www.w3.org/2000/svg" > the generated patches, we + <title>Discord Community Server</title> <g> observe that the LLM first @@ -20,6 +21,7 @@ export const Github = () => ( fixes two violations ❶ ❷ xmlns="http://www.w3.org/2000/svg" > by adding <title> ele+ <title>View Github Repository</title> <g> ments to individual SVG definitions (Figure 4c), but later resolves the third (c) LLM’s patch for Vio. ❶ ❷ in Fig. 3a. violation ❸ by adding src/components/icons.tsx an aria-label at the @@ -12,7 +12,7 @@ function Icons() { icon invocation level (Fig<div className="row-md-12"> <a href={x.url}> ure 4d). This later global + <a href={x.url} aria-label={x.name}> <svg className={x.classNames} …> fix conflicts with ear</a> lier local fixes, producing unintended side ef(d) LLM’s patch for Vio. ❸ in Fig. 3a. fects. Such conflicts arise Figure 4: A motivating example of because iterative repair introduced side effects after fixing. lacks awareness of previously applied repair actions and component-level dependencies. 1

Results and Analysis

3.2.1 Basic Repair Strategy. Under the Basic Repair Strategy, repair system processes the entire issue report with all violations in a single interaction. As shown in Table 1, although repair systems incur low costs, their repair capability remains constrained. Even the best-performing GUIRepair, reduces violations by only 31.52%. This limitation is attributable to the inherently multi-fault nature of web accessibility repair. As illustrated in Figure 1, accessibility violations on a single webpage are often numerous and widely distributed [64]. In A11YBench, 85.03% (125/147) of webpages contain more than 10 violations, and 12.24% (18/147) contain over 100 violations, indicating that large-scale multi-fault scenarios are common rather than exceptional. Such problem scale poses simultaneous challenges to both fault localization and patch generation. When a complete violation report is provided as input, repair systems are required to identify multiple faulty locations across different files and apply diverse fixes within a single generation. However, existing repair agents lack explicit mechanisms for task decomposition and hierarchical planning. As a result, they often fail to localize all relevant bug files and produce incoherent or incomplete patches when multiple fixes must be synthesized at once. These observations suggest that repair systems need explicit mechanisms for hierarchical planning and simplified patch synthesis to manage large and complex repair tasks effectively. Finding 1: The Basic Repair Strategy achieves low repair effectiveness despite minimal computational cost. Current LLM-based repair agents lack robust task planning and hierarchical reasoning, resulting in inaccurate fault localization and incoherent patches under multi-fault conditions.

3.2.2 Iterative Repair Strategy. Unlike the basic strategy, which receives all violations at once, iterative strategy processes each violation individually. As shown in Table 1, it achieves a higher resolve rate than basic strategy, but at the cost of reduced efficiency and increased side effects. We illustrate these limitations with examples. Repairing centrally repairable violations individually.

Huang et al. 1

Fault Localization Grouping

Patch Generation Grouping

Bug File 1 Bug File 1 Patch 4-1

Bug File 2 Bug File 2 Patch 4-2 Bug File 3 Bug File 3 Patch 4-3 Bug File 4 Bug File 4

All Violations Web Elements

Component-Level Violation Groups

Bug Files

Situation-Level Violation Situation-Level ViolationGroups Groups Situation-Level Situation-LevelViolation ViolationGroups Groups

Criterion-Level Violation Groups

Fault Localization

Patch 4-4

Patch Edits

Patch Generation

Chat Model Code-Base

Com-Group

Bug Bug Files BugFiles Files Files WCAG Req Bug WCAG Tec

Bug Files Bug BugFiles Files

Bug Files

Sit-Group

Bug Bug Files BugFiles Files Files WCAG Req Bug WCAG Tec

Chat Model

Bug Files Bug Files Patch Edits

Embedding Model

Need WCAG Guidelines? Com-Group

Sit-Group

Chat Model

Knowledge Integration

YES Finish

Know-Base

A11Y Checker

Bug BugFiles Files WCAG Req

Chat Model

Bug Files Bug Files WCAG Tec

Bug Bug Files BugFiles Files Files WCAG Req Bug WCAG Tec

Figure 2: The overview of A11YRepair. ❶-❷ It first groups all violations at the component and situation levels for fault localization and patch generation. ❸-❹ Then, it leverages chat and embedding models to locate buggy files and synthesize patch edits. ❺ Meanwhile, knowledge integration module selectively incorporates WCAG Requirements [29] and Techniques [57] for fault localization and patch generation.

These observations suggest that individually repairing violations that share root causes or structural dependencies is often inefficient and error-prone in practice. Effective web accessibility repair therefore requires grouping related violations and synthesizing coordinated repairs rather than treating each violation in isolation. Finding 2: The Iterative Repair Strategy improves repair precision compared with the Basic strategy but substantially increases cost. Its unawareness of violation relationships leads to redundant operations or side effects, limiting efficiency and stability in complex accessibility tasks.

3.2.3 WCAG Guided Repair Strategy. This design aims to investigate whether incorporating WCAG knowledge via Retrieval Augmented Generation (RAG) improves repair. As shown in Table 2, the WCAG-guided configuration slightly improves the resolve rate versus its non-guided counterpart (OpenHands𝑊 vs. OpenHands𝑊 /𝑂 ), but increases the overall computational overhead ($64.86 to $79.72). A closer inspection reveals that WCAG guidance effectiveness depends on whether the violation requires standards-level reasoning. For simple violations Table 2: Knowledge Guided Strategy. with explicit structural Systems 𝑅solve 𝑁 side 𝐶 total cues and well-known reOpenHands 61.53% 28 $64.86 𝑊 /𝑂 pair patterns (e.g., missOpenHands𝑊 69.23% 7 $79.72 ing text alternatives), LLMs can synthesize fixes without external guidance. For example, in the SVG icon case shown in Figure 3a, the model can directly add descriptive text to resolve the violation without consulting WCAG. In such cases, blindly retrieving guideline excerpts only increases context length and cost, while potentially introducing noise that distracts the model from straightforward repairs.

In contrast, complex violations require precise interpretation of WCAG Success Criteria. For instance, Figure 5: The requirement is for targets adjusting target size to be at least 24 by 24 CSS pixels in size. or spacing must satisfy SC 2.5.8 Target Size [60], which explicitly requires pointer targets to be at least 24 by 24 CSS pixels. As shown in Figure 5, such repairs demand adherence to quantitative thresholds and implementation-specific constraints difficult to infer without domain knowledge. These observations indicate that while WCAG knowledge is crucial for complex, standards-sensitive repairs, indiscriminately applying RAG to all violations is inefficient. Traditional RAG strategies lack a mechanism for LLMs to assess whether domain knowledge is necessary for a given violation, leading to wasted context budget for simple cases and suboptimal knowledge utilization. Finding 3: WCAG is essential for repairing complex, standards-sensitive violations, but provides limited benefit for simple cases with deterministic fixes. Blindly applying RAG to all violations increases cost and noise, highlighting the need for selective and context-aware knowledge invocation.

Approach

In this section, we present A11YRepair, an LLM-based framework designed to efficiently repair web accessibility violations through a goal-oriented divide-and-conquer strategy integrated with domain knowledge from WCAG. Similar to most APR works, A11YRepair

A11YRepair: Bridging Web Accessibility Barriers via Knowledge-Enhanced Divide-and-Conquer Repair

1920

Issue Report

Promo

79% Percentage of elements with no detected violations or items to review

4.3

12 mins·1km

4.5

10 mins·1km

4.1

15 mins·1.2km

4.5

Violations

3.29

FOOD 14 More cool features available on the app 17 18

/html[1]/body[1]/div[2]/main[1]/div[2]/div[1]/div[2]/a[1]

/html[1]/body[1]/div[2]/main[1]/div[2]/div[1]/div[3]/a[1]

/html[1]/body[1]/div[2]/footer[1]/div[1]/svg[1]

/html[1]/body[1]/div[2]/footer[1]/div[1]/p[1]

/html[1]/body[1]/div[2]/footer[1]/div[1]/p[2]

/html[1]/body[1]/div[2]/footer[1]/div[1]/p[3]

/html[1]/body[1]/div[2]/footer[1]/div[1]/a[1]/svg[1]

/html[1]/body[1]/div[2]/footer[1]/div[1]/a[2]/svg[1]

/html[1]/body[1]/div[2]/footer[1]/div[2]/a[1]/svg[1]

/html[1]/body[1]/div[2]/footer[1]/div[2]/a[2]/svg[1]

Component Grouping

15 mins·1.2km

4.5

12 mins·1.1km

Deliver date: Today

Deliver time: Now

Group Refining

See all promotions

600

There's something for everyone!

5.69

Grouping Size 1920*1080

4.69

3.29

Chat Model 8

FOOD Frequently Searched

Popular Cuisines

Support

More cool features available on the app

The SVG element has no accessible name

22 20

4.1

You are given a set of grouped webpage elements (with DOM path and accessibility violation counts) and a screenshot of the page with highlighted bounding boxes and numeric group indexes.

25 mins·1.5km

FOOD Frequently Searched

Popular Cuisines

Support

More cool features available on the app

Your task: 1. Observe the screenshot and the grouped elements (group_dict). 2. Determine whether the current grouping is reasonable. 3. If not, decide whether: - Some groups are **too fine-grained** (e.g., multiple groups are actually the same repeated component and should be merged). - Some groups are **too coarse-grained** (e.g., one group contains distinct components that should be split). 4. Output two lists: - `merge_groups`: list of group ids that should be merged together (too fine-grained). - `split_groups`: list of group ids that should be split into smaller groups (too coarse-grained). 5. If the grouping is already appropriate, output both lists as empty.

merge_groups

split_groups

list of group ids that should be merged together (too fine-grained).

list of group ids that should be split into smaller groups (too coarse-grained).

Home > Restaurant > Tea Break

Tea Break

Drinks & Beverages, Coffee & Tea 4.5

25 mins·1.5km

Deliver date: Today

Deliver time: Now

1 4

FOOD Frequently Searched

Popular Cuisines

Support

More cool features available on the app

750

Support 16

10 mins·1km

4.5

750

Popular Cuisines

/html[1]/body[1]/div[2]/main[1]/div[2]/div[1]/div[3]/img[1] /html[1]/body[1]/div[2]/main[1]/div[2]/div[1]/div[1]/a[1]

750

Frequently Searched 15

4.5

Drinks & Beverages, Coffee & Tea

Accessibility failures that need to be corrected

Element Dom Path

10 11

FOOD

●●●

Tea Break

Promo

1300

12 mins·1km

Promo

1300

4.69

4.3

Promo

1000

5.69

12 mins·1.1km

See all promotions

There's something for everyone!

1920 1

FOOD Home > Restaurant > Tea Break

Promo

Violations

700

Promo

900

Promo

Current Status 5

400

900

FOOD

200

FOOD ●●●

●●●

/html[1]/body[1]/div[2]/footer[1]/div[2]/a[3]/svg[1]

Detected Violation Elements

Issue Report

4 Grouped Components

8 Grouped Components

LLM’s Analyze

4 Grouped Components

Figure 6: The area-based grouping strategy.

Figure 7: The llm-based refining strategy.

follows the basic repair workflow, including fault localization and patch generation. Unlike prior work, A11YRepair introduces a hierarchical planning mechanism that decomposes complex repair tasks into manageable subproblems and embeds accessibility-specific expertise to improve both repair effectiveness and efficiency. As shown in Figure 2, A11YRepair integrates five components into a unified end-to-end workflow. The ❶-❷Violation Grouping Mechanism structures the overall process by hierarchically organizing violations into component- and situation-level groups, enabling modular and scalable repair. The ❸Fault Localization and ❹Patch Generation modules execute the repair operations, identifying relevant bug files and generating targeted edits guided by both textual and visual cues. Throughout these stages, the ❺WCAG-Driven Knowledge Integration module dynamically determines whether domain expertise is needed and selectively retrieves relevant Success Criteria and Techniques to support reasoning on complex violations. Finally, all patches are applied to the webpage, and an accessibility checker re-evaluates the repaired version to measure improvement.

DOM paths. For each violation, the system traverses its DOM hierarchy from the root and selects the closest ancestor node whose rendered size falls below a predefined threshold (e.g., 1920×1080). All violations sharing the same ancestor are grouped together, while isolated elements without a suitable ancestor remain independent. 2) LLM-based refining. Rule-based grouping alone cannot generalize across the structural diversity of real-world websites. Some UI elements, such as compact navigation bars, are visually small yet semantically distinct from adjacent content and should not be merged with the main body. Conversely, repeated instances of the same component may appear as multiple small groups but should be treated collectively. To handle these cases, A11YRepair employs an LLM-based strategy to refine the initial grouping result. As illustrated in Figure 7, the current grouping is rendered onto a webpage screenshot, where each group is visually highlighted and indexed with numeric identifiers. The model also receives structured metadata for every group, including violation types, DOM paths, and short DOM code snippets. The refinement objective is explicitly defined as grouping accessibility-violation elements that belong to the same UI component together. The LLM analyzes both the visual context and structural metadata to identify groups that should be merged (i.e., repeated or identical components) and those that should be split (i.e., overly broad clusters). Rather than performing direct merges or splits that could produce ambiguous or incorrect reassignments, A11YRepair adopts a conservative path-adjustment policy to implement the model’s recommendations. For groups to be merged, the grouping component path is adjusted upward by one DOM level (for example, from /html[1]/body[1]/div[2] to /html[1]/body[1]) so that broader ancestor nodes encompass multiple previously separate groups. For groups to be split, the grouping path is adjusted downward by one level to obtain finer granularity. This path-based adjustment effectively avoids combinatorial ambiguity and provides fine-grained control over grouping granularity. As a single adjustment round may not yield the optimal structure, refinement is performed iteratively. After each adjustment, A11YRepair re-renders the updated grouping, presents the result to the LLM, and repeats the refine–adjust cycle until the model indicates no further changes or a preset iteration limit is reached. The final output is a set of refined component-level violation groups that capture both structural coherence and semantic distinctness. Each refined group is then treated as a single logical component and passed to the fault-localization module, where grouped violations are jointly analyzed to identify the relevant files for targeted repair. By localizing violations at the component level rather than in isolation, this grouping strategy enables A11YRepair to reason about

4.1

Violation Grouping Mechanism

As revealed in Finding 1, existing agent systems often lack effective planning capabilities for complex scenarios, making them not suited to handle large numbers of interdependent web A11Y violations. In Finding 2, a naive divide-and-conquer strategy that feeds each violating element iteratively to the repair system can simplify the task but usually results in inefficient workflows and frequent side effects caused by redundant operations. To address this limitation, A11YRepair adopts a goal-oriented divide-and-conquer strategy that compensates for the limited planning capacity of LLMs. This strategy decomposes complex repair tasks into smaller, semantically coherent groups, allowing the system to balance repair cost and effectiveness more efficiently. It operates in two coordinated phases: Fault Localization Grouping and Patch Generation Grouping. 4.1.1 Fault Localization Grouping. Inspired by the recent web generation work [62], A11YRepair employs a goal-oriented divideand-conquer grouping strategy to organize A11Y violations into semantically coherent component-level groups for efficient fault localization, which includes two stages: a deterministic area-based initial grouping and an LLM-based refinement that adjusts grouping granularity based on the page’s structural and semantic layout. 1) Area-based grouping. The area-based grouping stage provides a fast and language-agnostic method for deriving an initial set of component containers. As shown in Figure 6, after running the A11Y checker (e.g., IBM Accessibility Checker [30]) on a webpage, A11YRepair collects all detected violations and their corresponding

Huang et al.

shared structure, styling, and behavior across related elements. This design not only reduces redundant localization effort but also lays the foundation for root-cause–aware patch generation, where multiple related violations can be repaired coherently. 4.1.2 Patch Generation Grouping. After violations are localized into component-level groups, A11YRepair further refines these groups for patch synthesis. While fault localization grouping determines where to repair by identifying relevant components and files, it does not distinguish how different violations within the same component should be repaired. As highlighted by our motivating study (Finding 2), treating all violations within a component individually can lead to redundant edits and unintended side effects, especially when multiple violations stem from shared root causes. Patch Generation Grouping addresses this issue by decomposing each component-level group into smaller, semantically coherent subsets, such that violations sharing the same underlying cause are repaired jointly. As shown in Figure 8, the Patch Generation Grouping process proceeds in two hierarchical steps: criterionbased grouping and situation-based grouping. 1 1

img_alt_valid 2

SC 1.1.1 Non-text Content

svg_graphics_labelled 3

1 Component-level Group SC 1.4.3 Contrast (Minimum)

2 Criteria-level Groups

text_contrast_sufficient

3 Situation-level Groups

Figure 8: The criterion/situation level grouping strategy. 1) Criterion-based grouping. Given a component-level group obtained from the Fault Localization Grouping phase, all detected violations within the component are first clustered according to their violated WCAG Success Criteria (i.e., Requirements [29]). This produces a set of criterion-level groups, each corresponding to a specific accessibility principle. For example, text_contrast_sufficient violations map to SC 1.4.3: Contrast, label_name_visible violations correspond to SC 2.5.3: Label in Name. These mappings derive from the A11Y checker’s rule–criterion associations (e.g., IBM Requirements [28]), allowing clustering of violations by criterion type. 2) Situation-based grouping. Each criterion-level group is then refined into situation-level groups based on the specific contexts defined within WCAG SC. For instance, under SC 1.4.3 Contrast [59], WCAG differentiates situations according to text size and weight: • Situation A: Text smaller than 18pt (or 14pt if bold) must achieve a contrast ratio of at least 4.5:1 (Technique G18). • Situation B: Text of at least 18pt (or 14pt if bold) must achieve a contrast ratio of at least 3:1 (Technique G145).

A11YRepair uses the violation messages returned by the accessibility checker to infer such situational contexts and perform message-level grouping automatically. By clustering violations into situation-level groups, the system decomposes complex, multiintent repair tasks into smaller, semantically coherent subtasks. This design enables the LLM to generate focused, consistent, and WCAGcompliant patches guided by relevant WCAG Techniques [57]. Importantly, this patch generation grouping strategy enforces root-cause–aware repair by ensuring that violations sharing the

same underlying cause are fixed jointly rather than individually. By synthesizing a single coordinated patch for each situation-level group, A11YRepair avoids the conflicting or redundant edits that often arise when similar violations are repaired in isolation.

4.2

Fault Localization and Patch Generation

After grouping all violating elements on the web page, we obtain Component-level and Situation-level Groups for fault localization and patch generation, respectively. Here, we draw inspiration from mainstream agentless repair systems’ workflow design principles [26, 67] to implement fault localization and patch generation. We also perform specialized design optimizations tailored to web bug repair scenarios to better map relationships between web elements and code files, while carefully avoiding conflicts introduced to the entire webpage by applying patch edits. Next, we will introduce the specific Fault Localization and Patch Generation process. 4.2.1 Fault Localization. The fault localization module leverages both the structural and visual characteristics of front-end web development to identify the source files responsible for accessibility violations. Unlike traditional back-end localization, which requires reasoning over control and data flows, front-end accessibility issues are tightly coupled with the visual presentation of UI components and their corresponding DOM identifiers (e.g., id, class, and text attributes). Existing APR systems, primarily designed for codecentric reasoning, often fail to utilize these front-end visual cues effectively [9, 37, 63, 67, 70, 72]. To address this gap, A11YRepair introduces a reflective localization process that combines visual and textual evidence and iteratively refines its predictions, mimicking the hypothesis-testing process of human developers. ② partial key bug files, need to search more files. Chat Model

Enough Bug Files?

Grouped Component

① all key bug files, output key files and finish FL.

Chat Model

③ no key bug files, need to relocate all bug files.

Embedding Model

Codebase

Initial Bug Files

LLM’s Reflection

Figure 9: The fault localization process, including File Localization (blue) and Locate Reflection (green). 1) File Localization. As shown in Figure 9, A11YRepair combines a chat model and an embedding model to identify potential bug files, following the general agentless paradigm [26, 67]. • Chat Model-based Localization: The chat model receives structured violation-related information for a single component, including the A11Y bug report, relevant WCAG guidelines (if available), and annotated screenshots. Following Agentless [67], we extract the repository structure and prompt the model to locate potential bug files by integrating its understanding of the violation data, visual cues, and repository layout. To enhance contextual reasoning, we include both the violation types detected by the A11Y checker and the corresponding DOM tree code of each violated element. A configurable slicing parameter 𝑁 determines how much surrounding DOM context to preserve. For example, 𝑁 = 1 retains one level of ancestor and sibling

A11YRepair: Bridging Web Accessibility Barriers via Knowledge-Enhanced Divide-and-Conquer Repair

nodes, while a larger 𝑁 extends the code context proportionally. For visual input, we capture a predefined region (e.g., 1920×1080) of the target component; if it exceeds this size, the screenshot is dynamically resized to cover the full component area. This strategy limits token consumption while maintaining full visibility of the relevant region. Consistent with GUI testing practices, each violation element is indexed and labeled with a numeric identifier on the screenshot, allowing the model to directly associate frontend visuals with reported violations. • Embedding Model-based Localization: The embedding model complements the chat model by retrieving files using attributebased similarity. It extracts the DOM attributes of each violated element (e.g., ID, CLASS, TEXT ) and performs a symbolmatching search across the repository to identify the top-𝑁 potentially related files. Each file is ranked by the frequency of matching attributes, ensuring focus on UI-related code while filtering out unrelated files. Because some configuration or build files may still be included, the chat model is again invoked to discard irrelevant entries before final retrieval. The embedding model then computes semantic similarity between the issue report and the filtered candidate files, returning the top-𝑀 most relevant ones. This two-step process narrows the search space to files most closely aligned with the violated UI elements, substantially reducing retrieval costs. Finally, A11YRepair merges the outputs of both models using a union operation to obtain the initial candidate set of bug files. 2) Locate Reflection. To overcome the rigidity of single-pass localization in prior systems [26, 67], A11YRepair treats fault localization as a multi-turn reflective process. As shown in Figure 9, after producing an initial set of candidate bug files, the LLM iteratively evaluates whether these files contain the key bug files—those that must be modified to resolve all accessibility violations. This reflection mechanism allows the model to analyze inter-file relationships and progressively refine its hypotheses, reducing the risk of missing critical files that contribute to the violation. During each iteration, the model receives the violation-related information, WCAG guidelines, annotated screenshots, and initial candidate bug files. It is then prompted to reason about whether the set covers all, partial, or none of the required fixes. Based on this reasoning, the model executes one of three adaptive behaviors: • All Key Files Identified. If the model concludes that the current candidate set already contains all key bug files, it outputs them as the final result and terminates localization. • Partial Coverage Detected. If only part of the key files are found, the model restarts the localization phase using contextual cues from the current results to search for additional files. • No Relevant Files Found. If none of the current candidates are relevant, the model revises its reasoning strategy and reinitializes the search from a new perspective.

This iterative reflection continues until the LLM determines that all key files have been identified or the max iteration limit is reached. 4.2.2 Patch Generation. With component-level violation groups localized to bug-related files, A11YRepair synthesizes concrete code edits to resolve issues. Since a component may contain multiple violations arising from different root causes, repairing them individually can introduce unintended side effects. To mitigate this risk, A11YRepair generates patches at the granularity of situation-level

violation groups, jointly repairing violations with shared causes while handling distinct causes in separate rounds. This strategy reduces generation complexity and prevents fixes for one violation from interfering with others within the same component. To ensure stable edits across potentially multiple files, A11YRepair emits patches in a structured search/replace format [67], enabling deterministic modification locations. Each patch is applied incrementally and validated via a lightweight rebuild-and-render check, and is accepted only if the webpage renders correctly without introducing new console errors. This conservative validation loop avoids destructive changes and supports reliable patch applying.

4.3

WCAG-Driven Knowledge Integration

Web A11Y repair inherently depends on domain standards such as WCAG, which define Success Criteria and Techniques for detecting and resolving violations. However, as shown in Finding 3, simply injecting retrieved guidelines causes excessive context, redundant reasoning, and inconsistent knowledge usage. To address this, A11YRepair adopts a goal-oriented knowledge enhancement strategy that selectively integrates WCAG guidance in a context-aware manner. Inspired by ReAct [74], A11YRepair enables reflect before using knowledge: it first analyzes whether the current situation warrants WCAG consultation, then decides what knowledge to apply. This reflection-before-knowledge process balances contextual relevance and computational efficiency. A11YRepair implements this adaptive integration through a two-stage reflective decision process: SC 1.1.1: Non-text Content

Technique ARIA6

Techniques

Examples

Situation A: If a short description can serve the same purpose and present the same information as the nontext content: using one of the following techniques for Situation A

Example 1: Distinguishing navigation landmarks The following example shows how aria-label could be used to distinguish two navigation landmarks in an HTML document, where there are more than two of the same type of landmark on the same page, and there is no existing text on the page that can be referenced as the label.

Short text alternative techniques for Situation A: •ARIA6: Using aria-label to provide labels for objects •ARIA10: Using aria-labelledby to provide a text alternative for non-text content •G196: Using a text alternative on one item within a group of images that … •H2: Combining adjacent image and text links for the same resource •H37: Using alt attributes on img elements •H53: Using the body of the object element •H86: Providing text alternatives for emojis, emoticons, ASCII art, and leetspeak •PDF1: Applying text alternatives to images with the Alt entry in PDF documents

Situation B: If a short description can not serve the same purpose and present the same information as the non-text content (e.g., a chart or diagram): using one of the following techniques for Situation B Short text alternative techniques for Situation B:

<div role="navigation" aria-label="Primary"> <ul> <li>...a list of links here ...</li> </ul> </div> <div role="navigation" aria-label="Secondary"> <ul> <li>...a list of links here ...</li> </ul> </div>

Example 2: Identifying region landmarks The following example shows how a generic "region" landmark might be added to a weather portlet. There is no existing text on the page that can be referenced as the label, so it is labelled with aria-label. <div role="region" aria-label="weather portlet"> ... </div>

Figure 10: Example of Success Criteria and Techniques. 1) Necessity Analysis (Reflection on “Whether”). Before incorporating WCAG knowledge, LLMs reflect on whether external guidance is needed for the current violation group. Given the A11Y bug report and annotated screenshot, the model assesses violation complexity. If the violations are simple (e.g., missing alt attributes), it outputs "wcag_required":"NO" and skips enhancement. If the violations involve complex patterns (e.g., ARIA attributes, dynamic components, or keyboard interactions), it outputs "YES" and proceeds to next stage. This reflection step ensures that knowledge retrieval is invoked only when truly necessary. 2) Technique Selection (Reflection on “What”). Once WCAG knowledge is deemed necessary, A11YRepair retrieves specific Success Criteria associated with violations (e.g., SC 1.1.1 Non-text Content [58] for missing alt text). The LLM is provided with the violation

Huang et al.

context and the relevant SC documentation, and it then identifies applicable techniques from the “Sufficient” and “Advisory” sections (e.g., ARIA6, G73, H37). Figure 10 shows an example under SC 1.1.1, where each technique specifies actionable repair strategies. The LLM outputs selected technique IDs along with explanatory reasoning. Finally, detailed SC and technique documentation are selected and merged into a curated knowledge context used to guide repair.

5 Experiment Setup 5.1 Research Questions • RQ1: How effective is A11YRepair compared with other SOTA repair systems? • RQ2: How does each component contribute to the overall repair capability? • RQ3: Can A11YRepair generalize to unseen task instances and base models? • RQ4: How practical is A11YRepair in improving real-world web accessibility?

Benchmark and Implementation

• Benchmark: We evaluate all tools in A11YBench [1], which is divided into two versions: Lite contains 10 repositories, Full contains all 60 repositories. We use the small-scale A11YBench-Lite to evaluate the overall effectiveness, and the larger-sample A11YBench-Full for conducting the generalizability study. • Implementation: We use o4-mini-2025-04-16 [47] as the chat model and text-embedding-3-small [48] as the embedding model in the implementation of A11YRepair. More details and settings are available in our artifact [2].

Evaluation Metrics

• Violation Solve Rate: Following prior work [16, 24], we measure repair effectiveness by comparing the number of violations detected before and after patch application. We use the IBM A11Y Checker to extract the violation sets Vbefore and Vafter . The solve rate is defined: 𝑅solve = ( | Vbefore | − | Vafter | )/| Vbefore | . • Side Effect Count: A good repair system should avoid introducing sides effects [25, 40]. We therefore measure the number of newly created violations after repair, a smaller 𝑁 side reflects better stability and fewer unintended regressions: 𝑁 side = | {𝑣 | 𝑣 ∈ Vafter ∧ 𝑣 ∉ Vbefore } | . • Token Usage Cost: We do not measure runtime due to its dependence on external factors such as hardware and parallelism. To evaluate cost-efficiency, we compute the total LLM tokens consumed during end-to-end repair. Let 𝑇total denote total token usage and 𝑃 denote the per-token cost: 𝐶 total = 𝑇total × 𝑃 .

1920

GUIRepair𝐵 𝑅solve 𝑁 side 𝐶 total

GUIRepair𝐼 𝑅solve 𝑁 side 𝐶 total

GUIRepair𝑊 𝑅solve 𝑁 side 𝐶 total

A11YRepair 𝑅solve 𝑁 side 𝐶 total

TypeScript golang carbon tailwindcss pnpm.io Algorithms electron lynx asyncapi posthog

80 56 53 225 145 634 553 504 79 293

57.50% 37.50% 62.26% 59.82% 8.28% 29.81% 59.86% 22.82% 1.98% 2.19%

0 0 2 3 85 2 86 15 1 6

$1.00 $0.30 $0.73 $0.41 $0.60 $0.53 $0.65 $0.69 $0.45 $0.89

73.75% 69.64% 66.04% 70.09% 66.90% 79.18% 83.25% 60.98% 64.56% 72.07%

14 0 0 41 4 130 23 56 22 20

$6.49 $3.60 $3.38 $9.15 $6.63 $22.03 $24.20 $21.21 $3.73 $31.63

85.00% 57.14% 58.49% 40.00% 68.97% 86.75% 87.16% 51.59% 82.28% 68.60%

0 7 14 103 7 84 14 25 6 31

$6.40 $3.99 $5.09 $18.82 $11.29 $35.07 $32.88 $19.40 $1.75 $27.94

81.25% 69.64% 84.91% 74.22% 70.34% 91.17% 89.33% 68.65% 65.82% 54.95%

12 0 2 50 0 27 8 43 13 17

$2.54 $2.00 $1.26 $8.53 $6.42 $3.65 $8.72 $12.86 $1.47 $11.98

#Total

2622

32.22%

200

$6.24

73.19%

310

$132.03

71.66%

291

$162.63

78.15%

172

$59.43

400 400

Searches

Quick Select

Searches

Linear Search

Searches

Fibonacci Search

Searches

Jump Search

Searches

Double Linear Search

Searches

Iterative Binary Search

Searches

Exponential Search

Searches

Binary

Searches

Tabu Search

Searches

Native Search

The Algorithms

ABOUT

Search any algorithm

DONATE

2 Searches

Searches

Interpolation Search

Quick Select

Fibonacci Search

Searches

Binary Search

Linear Search

Jump Search

Searches

Double Linear Search

Exponential Search

Tabu Search

Searches

Iterative Binary Search

Binary

Native Search

The Algorithms Open Source resource for learning DSA. Join our community of open source developers and learn and share implementations for algorithms and data structures in various languages. Learn, share, and grow with us.

700

Vio.

Searches

Binary Search

600

2000

Repo

Searches

Interpolation Search

600

DONATE

700

Table 3: Repair Results on A11YBench-Lite (using o4-mini).

600

1920 ABOUT

Search any algorithm

2000

We select GUIRepair [26] as the primary baseline because it follows the same agentless pipeline [67] as A11YRepair and achieved the strongest performance in our motivating study and SWE-Bench leaderboard [55]. Following that setup, we evaluate GUIRepair variants: Basic Repair Strategy, Iterative Repair Strategy, and WCAG Guided Repair Strategy, denoted as GUIRepair𝐵 , GUIRepair𝐼 , and GUIRepair𝑊 . Table 3 summarizes the overall results. Overall, compared to best GUIRepair𝐼 , A11YRepair improves the resolve rate by 4.96%, reduces side effects by 44.52%, and lowers token cost by 54.99%. These results demonstrate the effectiveness of its divideand-conquer design in balancing repair quality, stability, and cost.

The Algorithms

200

6 Evaluation 6.1 RQ1: Overall Effectiveness

400

5.3

RQ2: Ablation Study

In the ablation study, we Table 4: Ablation study. aim to evaluate the contriVariants 𝑅solve 𝑁 side 𝐶 total butions of A11YRepair’s de❶ Impact of Grouping Granularity sign choices in enhancing A11YRepair𝑐𝑜𝑚 59.01% 377 $43.75 the repair capability. Given A11YRepair𝑐𝑟𝑖 64.91% 288 $51.07 that checking patches for A11YRepair𝑠𝑖𝑡 78.15% 172 $59.43 syntax errors and perform❷ Impact of LLM-based Refining A11YRepair𝑤/𝑜𝑟 69.35% 355 $108.76 ing visual inspections to A11YRepair𝑤/𝑟 78.15% 172 $59.43 filter invalid patches have ❸ Imapct of Feature Retrieval been extensively applied in A11YRepair𝑤/𝑜𝑒 69.64% 400 $52.06 prior work, patch generaA11YRepair𝑤/𝑒 78.15% 172 $59.43 tion strategies are not ex❹ Impact of Locate Reflection plored as our primary deA11YRepair𝑤/𝑜𝑙 66.25% 373 $46.16 A11YRepair𝑤/𝑙 78.15% 172 $59.43 sign contribution. There❺ Impact of Knowledge Integration fore, We focus on evaluA11YRepair𝑛𝑤 74.94% 194 $53.84 ating how our key design A11YRepair𝑎𝑤 58.74% 498 $75.79 choices of A11YRepair, inA11YRepair𝑠𝑤 78.15% 172 $59.43 cluding violation grouping, fault localization, and knowledge integration, contribute to its performance. Due to the high cost of large-scale experiments, all ablation studies are conducted on A11YBench-Lite. 1) Grouping Granularity. To examine the effect of divideand-conquer granularity, we evaluate 3 variants: A11YRepair𝑐𝑜𝑚 , A11YRepair𝑐𝑟𝑖 , A11YRepair𝑠𝑖𝑡 . These variants adopt component / criterion / situation-level grouping, respectively, enabling us to analyze how different levels of decomposition influence the result. Table 4 shows a clear trend: finer-grained grouping consistently improves repair effectiveness while reducing side effects. Although finer-grained grouping incurs a modest cost increase, A11YRepair𝑠𝑖𝑡 achieves the best overall trade-off. These results indicate that finer-grained grouping yields more homogeneous and contextually coherent subproblems, reducing LLM reasoning ambiguity and alleviating side effects.

400

5.2

6.2

14 Grouped Components

3 Grouped Components

(a) Grouping results before LLMbased refining.

(b) Grouping results after LLMbased refining.

Figure 11: A case of using LLM-based refining strategy. 2) LLM-based Refining. We further study the effect of LLMbased refining by comparing two variants: A11YRepair𝑤/𝑜𝑟 removes the refining step and uses only the area-based heuristic, whereas A11YRepair𝑤/𝑟 leverages the LLM to semantically adjust grouping decisions. Table 4 shows that incorporating LLM-based refining yields substantial improvements. Figures 11 presents a

A11YRepair: Bridging Web Accessibility Barriers via Knowledge-Enhanced Divide-and-Conquer Repair

case from Algorithms: the area-based grouping initially fragments several repeated algorithm-card components into separate groups (Figure 11a), whereas the LLM refining step correctly recognizes their shared semantics and merges them into a unified group (Figure 11b). Our further analysis shows that LLM refining merges 172 over-fragmented component groups and splits 6 over-clustered ones, eliminating redundant prompts and reducing unnecessary cost. By adaptively correcting heuristic grouping errors, the refining mechanism improves repair stability, prevents conflicting edits, and ensures consistent repairs across repeated components.

Chat Model

BUG FILES: /src/app/layout.tsx /src/app/page.tsx /src/components/home/explainer-section.tsx /src/components/home/tailwind-ui-section.tsx /src/… /home/why-tailwind-css-section.tsx

Violation 1: aria_content_in_landmark

Embedding Model

Feature Extract FEATURES_LIST: ["font-medium", "relative", "text-white", "max-xl:max-w-2xl", "max-lg:mt-60", "Adam Wathan", "max-lg:mx-auto", "xl:maxw-2xl", "text-gray-400", "mt-8", "text-2xl/10", "Creator of Tailwind CSS", "text-base/8", "lg:max-w-lg"]

/src/app/sponsor/page.tsx

Embedding Retrieval Feature Search

TOP_CANDIDATES: ["/src/app/sponsor/page.tsx",14], ["/src/app/build-uis-that-dont-suck/page.tsx",5], … ["/src/app/build-uis-that-dont-suck/subscribed/page.tsx",4]

Figure 12: A case of embedding model localization. 3) Feature Retrieval. During fault localization, A11YRepair extracts attribute-level cues from each violation element (e.g., component ID, key, and bounding box) to retrieve a focused set of structurally related candidate files. The embedding model then performs semantic retrieval within this reduced search space, alleviating the limitations of relying solely on a chat model, which often lacks structural grounding and may overlook files linked through UI feature correlations. To assess its impact, we compare the full system with embedding-based retrieval (A11YRepair𝑤/𝑒 ) against a variant that relies solely on the chat model (A11YRepair𝑤/𝑜𝑒 ). Table 4 shows that incorporating feature retrieval (A11YRepair𝑤/𝑒 ) yields a clear improvement over the chat-only variant (A11YRepair𝑤/𝑜𝑒 ). To understand this improvement, we examine a case from tailwindcss.com (Figure 12). The violation is a text block triggering the rule aria_content_in_landmark. Without feature retrieval, the chat model incorrectly predicts four unrelated files as potential bug files (layout.tsx, page.tsx, explainer-section.tsx, tailwind-ui-section.tsx). In contrast, the feature-guided embedding module correctly identifies /src/app/sponsor/page.tsx as the true bug file by leveraging contextual attributes such as component IDs (FEATURE_LIST). These features allow the embedding model to rank the correct file first (TOP-1 in TOP_CANDIDATES) without chat model inference. This shows that feature retrieval provides a fast, structurally grounded signal that complements the chat model and improves fault localization while reducing repair instability. 4) Locate Reflection. To address incomplete initial localization, A11YRepair introduces a Locate Reflection step that enables the LLM to verify whether the currently located files are sufficient. We evaluate its effect by comparing a variant without the locate reflection (A11YRepair𝑤/𝑜𝑙 ) and the full version (A11YRepair𝑤/𝑙 ). As shown in Table 4, A11YRepair𝑤/𝑙 improves the resolve rate by 11.9% and reduces side effects by 53.89% over A11YRepair𝑤/𝑜𝑙 , with only minor token overhead. These gains arise because Locate Reflection both prunes irrelevant files from the initial localization

and expands the candidate set when essential files are missing, transforming localization from a one-shot prediction into a selfcorrective process. 5) Knowledge Integration. We examined the impact of WCAGdriven knowledge integration strategy by 3 variants: A11YRepair𝑛𝑤 , which removes all WCAG knowledge; A11YRepair𝑎𝑤 , which injects WCAG guidance for every instance; and A11YRepair𝑠𝑤 , which selectively incorporates WCAG content. This comparison allows us to assess whether external WCAG improves repair effectiveness over no knowledge at all, and whether selective, reflectiondriven usage yields better results than unconditional, always-on knowledge injection. As shown in Table 4, the selective-with-WCAG variant (A11YRepair𝑠𝑤 ) delivers the best overall performance, improving the violation resolve rate by 3.21% and reducing sideeffect violations by 20 compared with the no-knowledge version (A11YRepair𝑛𝑤 ), while also outperforming the always-with-WCAG variant (A11YRepair𝑎𝑤 ) by a large margin in both resolve rate (78.15% vs. 58.74%) and side effects (172 vs. 498), with lower token cost as well ($59.43 vs. $75.79). These results reveal that WCAG knowledge is indeed helpful when applied selectively, since it provides targeted domain cues for complex violations that require explicit accessibility reasoning, yet unconditional WCAG injection often harms performance by introducing irrelevant or distracting context for simple violations the model can already solve.

6.3

RQ3: Generalizability Study

In this section, we evaluate whether our approach can be generalized to additional base models and unseen repositories. 1) Generalization Table 5: Repair results of A11YRepair across base models. with different base models. To assess cross-model Base Models 𝑅solve 𝑁 side 𝐶 total generalization, we furGPT-4.1 mini 60.45% 461 $21.03 ther replace the base o4-mini 78.15% 172 $59.43 model while conductGPT-5 mini 77.93% 157 $21.03 ing experiments on Gemini-2.5-flash 75.41% 171 $34.16 A11YBench-Lite. As Gemini-2.5-pro 79.56% 101 $106.80 shown in Table 5, Gemini-3.0-flash 80.62% 125 $92.53 stronger models yield Kimi-K2.5 80.63% 322 $28.80 consistently better repair outcomes. Using recent released models Gemini-3.0-flash and Kimi-K2.5, A11YRepair consistently maintains the resolution rate of around 80%. These results indicate that A11YRepair is modelagnostic and benefits from stronger base models: more capable reasoning engines amplify the effectiveness and cost-efficiency of the multi-stage repair pipeline. 2) Generalization Table 6: Repair results on A11YBenchacross repositories. Full with o4-mini. Table 6 reports the results of A11YRepair Repair Systems 𝑅solve 𝑁 side 𝐶 total on A11YBench-Full, it GUIRepair𝐵 36.27% 456 $19.36 contains 60 repositoGUIRepair𝐼 60.14% 2387 $479.98 A11YRepair 76.82% 679 $160.15 ries. When using the o4-mini, A11YRepair achieves the highest resolve rate of 76.82%, outperforming GUIRepair𝐼 by 16.68% and GUIRepair𝐵 by 40.55%. In terms of repair

Huang et al.

stability, A11YRepair introduces only 679 new side-effect violations, which is 71.51% fewer than GUIRepair𝐼 , and comparable to the lowest baseline GUIRepair𝐵 . Furthermore, A11YRepair maintains a moderate repair cost of $160.15, reducing cost by 66.63% compared to GUIRepair𝐼 ($160.15 vs. $479.98). These results demonstrate that the divide-and-conquer repair strategy of A11YRepair remains robust and scalable, and that its advantages are even more pronounced on larger and more diverse project sets.

6.4

RQ4: Usefulness Evaluation

Evaluating only on benchmark is insufficient. We further investigate the usefulness of A11YRepair in real-world development settings: 1) Multi-Round It- Table 7: Multi-round repair result erative Repair. In prac- (Gemini-2.5-flash). tice, A11Y repair is Repair Rounds 𝑅solve 𝑁 side 𝐶 total verification-driven and Turn-1 75.41% 171 $34.16 rarely one-shot: develTurn-2 85.99% 85 $49.31 opers iteratively fix isTurn-3 87.49% 55 $59.85 sues and rerun checkers to validate results. To evaluate whether A11YRepair supports this workflow, we conduct a multi-round repair where checker feedback from each round guides subsequent repairs. As shown in Table 7, A11YRepair steadily improves across rounds: after three iterations, the repair rate increases from 75.41% to 87.49%, while introduced side effects drop from 1.9% to 0.6%. This shows that A11YRepair leverages post-repair verification to iteratively refine fixes, rather than relying on a single attempt. 2) Manual Patch Table 8: Repair results after manual Validation. Since check- checking. ers may produce false Evaluation 𝑉before 𝑉after 𝑅solve 𝑁 side positives or overlook A11Y Checker 2622 328 87.49% 55 semantic issues, we manManual Check 2433 277 88.61% 56 ually audited the final repair results (Turn-3 in Table 7) to assess patch quality beyond checker signals. Specifically, we inspected whether the reported violation was semantically resolved, and the patch preserved the intended UI functionality and layout. As shown in Table 8, the manually validated resolve rate is comparable to, and slightly higher than, the checker-reported rate. However, we also explicitly examined 6 silent regressions not captured by the checker: Five cases were related to contrast repairs that altered subtle UI color semantics (e.g., state-indicating differences under hover or dropdown interaction), which require dynamic interaction to detect. One case involved minor layout spacing changes following structural edits. Although the observed silent regression ratio is low, these findings reveal two limitations of A11YRepair: dynamic UI state semantics and subtle layout-sensitive styling. Overall, manual audit confirms that A11YRepair produces semantically sound repairs under weak oracles, while also highlighting scenarios where human review remains beneficial. 3) Real-World Developer Feedback. To further assess the practicality of A11YRepair, we submitted patches generated by A11YRepair to GitHub projects. As a single web page may contain multiple violations and yield multiple patch edits, we follow previous work [79] randomly selected 1 patch per project for submission to avoid bias. Currently, 61 of submitted pull requests (PRs) have

Table 9: Developer acceptance of A11YRepair’s patches. No.

Repo

Star

PR ID

No.

Repo

Star

PR ID

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

angular/angular ant-design/ant-design OpenHands/GUI TryGhost/Ghost bytedance/deer-flow GitbookIO/gitbook recharts/recharts umijs/qiankun github/opensource alibaba/hooks ethereum/ethereum kubernetes/website docker/docs umijs/dumi vuejs/docs facebook/react-native rescript-lang/rescript ipld/ipld elementary/website php/web-php overthewire/website istio/istio.io mitre-attack/attack files-community/web jhipster/jhipster

100k 97.7k 69.3k 52.1k 31.3k 28.7k 26.8k 16.6k 15.3k 14.9k 5.9k 5.2k 4.5k 3.8k 3.2k 2.1k 1.9k 1.3k 1.3k 1.1k 1.1k 818 571 463 345

#66723 #56510 #12728 #25975 #844 #3934 #6872 #3101 #3597 #2892 #17139 #54097 #24013 #2307 #3327 #4956 #1170 #363 #3966 #1787 #173 #17108 #564 #826 #1550

26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

socketio/socket.io carbondesign/web pnpm/pnpm.io OpenRefine/org kedacore/keda lutris/website apache/apisix apache/doris verge/currency apache/seata microsoft/aspire vitessio/website kubeedge/website openfeature/dev spring-ai/website asyncapi/website goharbor/website milkdown/website spiffe/spiffe.io remix-run/remix rook/github.io shorebirdtech/web google/trillian mlflow/mlflow SWE-bench/io

343 319 287 154 149 149 146 126 110 109 109 63 60 60 60 47 45 41 31 30 25 19 15 15 12

#520 #4784 #743 #507 #1700 #750 #1985 #3327 #1265 #1061 #299 #2064 #758 #1329 #259 #904 #700 #250 #368 #373 #177 #402 #129 #429 #44

already been merged, 4 PRs have been approved. Due to space limitations, Table 9 shows only the top 50 merged PRs, full lists please see [4]. Notably, several patches were accepted by popular projects, including Google’s angular, Microsoft’s aspire, Facebook’s react-native-website, IBM’s carbon-website, Bytedance’s deer-flow, Ant Group’s ant-design, and Alibaba’s spring-ai and hooks. However, we also observed one rejection (openclaw.ai #34), where a contrast change was declined because the developer preferred weaker visual contrast. This example is instructive: satisfying WCAG constraints does not automatically imply alignment with branding or aesthetic intent. Accessibility repair therefore benefits from human-in-theloop collaboration, rather than fully autonomous deployment. Overall, real-world adoption demonstrates that patches of A11YRepair are generally practical and developer-acceptable. Furthermore, we observed that A11YRepair can resolve violations rooted in third-party components. For example, when repairing a violation reported in ant-design #56521, A11YRepair identified that the violation element originated from an external component rather than the application itself. Following developers’ guidance, we applied A11YRepair to the repository of the third-party component and generated a fix in dumi #2307, which has been successfully merged. This demonstrates that A11YRepair generalizes beyond single-application repair and can operate at framework level.

Threats to Validity

Data Leakage. Unlike many APR benchmarks that derive tasks from GitHub pull request histories [33, 34, 73], which risks exposing ground-truth fixes during LLM training. A11YBench is constructed from violations detected by the A11Y Checker. This design avoids leaking the ground truth fixes into model pretraining corpora. Weak Oracles. A11Y checkers may introduce false positives, so provide weak repair oracles to threaten the validity. We mitigate this risk by using IBM A11Y Checker [30], which offers good reported precision (97.5%) and highest recall among rule-based checkers [23].

A11YRepair: Bridging Web Accessibility Barriers via Knowledge-Enhanced Divide-and-Conquer Repair

Importantly, the manual audit, low silent regression count, and realworld PR acceptance collectively provide independent validation signals beyond the single checker. The empirical evidence suggests that improvements are not merely checker-specific artifacts.

work motivates further research on principled LLM-based program repair and contributes to building a more inclusive web ecosystem.

Data Availability Statement

Artifact is available via an online website [2] and Figshare [3].

Related Work

Automated Program Repair. Traditional work including searchbased [36], constraint-based [46], and template-based methods [38] have recently evolved toward LLM-driven systems [25, 71, 76]. For example, AlphaRepair [69], ChatRepair [70], and Gamma [77] demonstrate how pretrained knowledge can yield human-like fixes. Especially, recent efforts explore autonomous repair agents [9, 11, 44, 49, 56, 63, 68, 72, 75, 81]. These systems mimic human debugging to implement the repair workflow. Unlike the general purpose repair systems, A11YRepair is the first repo-level web A11Y repair tool. Web Accessibility Detection. Web A11Y detection [12, 13, 32, 54] follows standards such as WCAG [61]. These guidelines enabled the development of checkers [18, 30, 53, 65]. While effective for syntactic or layout violations, static checkers struggle with semantic issues, e.g., whether an image’s alt text reflects its visual content. Recent work [16, 23] leverage LLMs to identify semantic issues. These advances provide a foundation for our study: A11YRepair addresses the remaining challenge by turning detected violations into actionable fixes for the end-to-end accessible web development. Web Accessibility Correction. Early work relied on rule-based HTML/DOM transformations [5, 17] or expert-in-the-loop methods [39, 51], while others addressed specific violations using computer vision, such as alt-text generation [66]. However, these methods have limited coverage and robustness. Recent studies leverage LLMs to assist web A11Y correction, including LLM-based DOM rewriting [16, 24] and coding assistance for accessible design [45]. Still, existing tools only work on rendered DOM/HTML, providing temporary patches that do not modify the underlying source code. It means that these tools cannot help developers address accessibility issues fundamentally. This also explains why our experiment did not adopt previous work. In contrast, A11YRepair performs source-level, repository-wide repair of A11Y violations. By combining divide-and-conquer grouping and selective WCAG-guided reasoning, A11YRepair delivers practical fixes in real-world projects. Mobile Accessibility Enhancement. Accessibility also have been studied in the mobile platform [6, 7, 19, 22, 35, 41–43, 50, 79, 80]. Prior work mainly targets specific issue types, such as annotating UI elements [78], predicting semantic labels [10], and repairing size [6] or color [79] related accessibility issues. Recent studies explore LLM for mobile A11Y. Representative efforts include using multi-agent systems to generate repair suggestions for IOS development [40], and leverage visual reasoning to automate alt-text generation [21]. However, existing methods are largely platformspecific and problem-oriented, limiting generalizability. Extending A11YRepair to mobile platforms is an key direction for future work.

Conclusion

Web A11Y violations remain widespread in modern web systems. By decomposing violations into goal-oriented subproblems and injecting domain-specific knowledge derived from WCAG, A11YRepair enables more reliable and scalable source-level repair. We hope this

References [1] A11YBench. 2026. A11YBench. Retrieved Mar 26, 2026 from https://sites.google. com/view/a11yrepair/a11ybench [2] A11YRepair. 2026. A11YRepair. Retrieved Mar 26, 2026 from https://sites.google. com/view/a11yrepair [3] A11YRepair. 2026. Figshare. Retrieved Mar 26, 2026 from https://doi.org/10.6084/ m9.figshare.31896229 [4] A11YRepair. 2026. Impact. Retrieved Mar 26, 2026 from https://sites.google.com/ view/a11yrepair/impact [5] Suliman K Almasoud and Hassan I Mathkour. 2019. Instant adaptation enrichment technique to improve web accessibility for blind users. In Proceedings of the 2019 3rd International Conference on Information System and Data Mining. 159–164. [6] Ali S Alotaibi, Paul T Chiou, and William GJ Halfond. 2021. Automated repair of size-based inaccessibility issues in mobile applications. In Proceedings of the 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). 730–742. [7] Abdulaziz Alshayban and Sam Malek. 2022. AccessiText: automated detection of text accessibility issues in Android apps. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). 984–995. [8] Abdul Haddi Amjad, Muhammad Danish, Bless Jah, and Muhammad Ali Gulzar. 2025. Accessibility Issues in Ad-Driven Web Applications. In Proceedings of the 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). 2393–2405. [9] Islem Bouzenia, Premkumar Devanbu, and Michael Pradel. 2025. RepairAgent: An Autonomous, LLM-Based Agent for Program Repair. In Proceedings of the 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). 2188–2200. [10] Jieshan Chen, Chunyang Chen, Zhenchang Xing, Xiwei Xu, Liming Zhu, Guoqiang Li, and Jinshui Wang. 2020. Unblind your apps: Predicting naturallanguage labels for mobile gui components by deep learning. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering (ICSE). 322–334. [11] Zimin Chen, Yue Pan, Siyu Lu, Jiayi Xu, Claire Le Goues, Martin Monperrus, and He Ye. 2025. Prometheus: Unified Knowledge Graphs for Issue Resolution in Multilingual Codebases. arXiv preprint arXiv:2507.19942 (2025). [12] Paul T Chiou, Ali S Alotaibi, and William GJ Halfond. 2021. Detecting and localizing keyboard accessibility failures in web applications. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). 855–867. [13] Paul T Chiou, Robert Winn, Ali S Alotaibi, and William GJ Halfond. 2024. Automatically Detecting Reflow Accessibility Issues in Responsive Web Pages. In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE). 1811–1823. [14] Ant Design. 2026. Ant Design: An enterprise-class UI design language and React UI library. Retrieved Jan 13, 2026 from https://github.com/ant-design/ant-design.git [15] Ant Design. 2026. Ant Design: Help designers/developers building beautiful products more flexible and working with happiness. Retrieved Jan 13, 2026 from https: //ant.design/ [16] Nadeen Fathallah, Daniel Hernández, and Steffen Staab. 2025. AccessGuru: Leveraging LLMs to Detect and Correct Web Accessibility Violations in HTML Code. In Proceedings of the 27th International ACM SIGACCESS Conference on Computers and Accessibility. 1–22. [17] Mexhid Ferati and Lirim Sulejmani. 2016. Automatic Adaptation Techniques to Increase the Web Accessibility for Blind Users. In International 2016 - Posters’ Extended Abstracts - 18th International Conference, HCI, Vol. 618. 30–36. [18] Google. 2025. Lighthouse. Retrieved Oct 01, 2025 from https://developer.chrome. com/docs/lighthouse/ [19] Jiahao Gu and Huaxun Huang. 2025. Characterizing and Repairing Color-Related Accessibility Issues in Android Apps. (2025), 1–13. [20] Alexandra-Elena Guriţă and Radu-Daniel Vatavu. 2025. When LLM-Generated Code Perpetuates User Interface Accessibility Barriers, How Can We Break the Cycle. In Proceedings of the 22nd International Web for All Conference (W4A’25). [21] Sabrina Haque and Christoph Csallner. 2025. Early Accessibility: Automating Alt-Text Generation for UI Icons During App Development. arXiv preprint arXiv:2504.13069 (2025). [22] Ziyao He, Syed Fatiul Huq, and Sam Malek. 2024. “I Tend to View Ads Almost Like a Pestilence”: On the Accessibility Implications of Mobile Ads for Blind

Huang et al.

Users. In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE). 2432–2444. [23] Ziyao He, Syed Fatiul Huq, and Sam Malek. 2025. Enhancing Web Accessibility: Automated Detection of Issues with Generative AI. Proceedings of the ACM on Software Engineering 2, FSE (2025), 2264–2287. [24] Calista Huang, Alyssa Ma, Suchir Vyasamudri, Eugenie Puype, Sayem Kamal, Juan Belza Garcia, Salar Cheema, and Michael Lutz. 2024. Access: Prompt engineering for automated web accessibility violation corrections. arXiv preprint arXiv:2401.16450 (2024). [25] Kai Huang, Zhengzi Xu, Su Yang, Hongyu Sun, Xuejun Li, Zheng Yan, and Yuqing Zhang. 2024. Evolving paradigms in automated program repair: Taxonomy, challenges, and opportunities. Comput. Surveys 57, 2 (2024), 1–43. [26] Kai Huang, Jian Zhang, Xiaofei Xie, and Chunyang Chen. 2025. Seeing is Fixing: Cross-Modal Reasoning with Multimodal LLMs for Visual Software Issue Repair. In Proceedings of the 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). 1156–1168. [27] Syed Fatiul Huq, Abdulaziz Alshayban, Ziyao He, and Sam Malek. 2023. #A11yDev: Understanding Contemporary Software Accessibility Practices from Twitter Conversations. In Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems. 1–18. [28] IBM. 2025. IBM Accessibility Requirements: Here are the latest published rule sets in the IBM Equal Access Accessibility Checker. Retrieved Oct 01, 2025 from https://www.ibm.com/able/requirements/checker-rule-sets/ [29] IBM. 2025. IBM Accessibility Requirements: This page lists the accessibility requirements that need to be met for several standards and regulations. Retrieved Oct 01, 2025 from https://www.ibm.com/able/requirements/requirements/ [30] IBM. 2025. IBM Equal Access Toolkit. Retrieved Oct 01, 2025 from https://www. ibm.com/able/toolkit/ [31] IBM. 2026. Label in Name. Retrieved Jan 25, 2026 from https://www.ibm.com/ able/requirements/requirements/?version=v7_3#2_5_3 [32] Shubhi Jain, Syed Fatiul Huq, Ziyao He, and Sam Malek. 2025. Automated Detection of Web Application Navigation Barriers for Screen Reader Users. In Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). 1906–1918. [33] Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R Narasimhan. 2024. SWE-bench: Can Language Models Resolve Real-world Github Issues?. In The Twelfth International Conference on Learning Representations. [34] René Just, Darioush Jalali, and Michael D Ernst. 2014. Defects4J: A database of existing faults to enable controlled testing studies for Java programs. In Proceedings of the 2014 International Symposium on Software Testing and Analysis (ISSTA). 437–440. [35] Arun Krishnavajjala, SM Hasan Mansur, Justin Jose, and Kevin Moran. 2024. Motorease: Automated Detection of Motor Impairment Accessibility Issues in Mobile App UIs. In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering (ICSE). 2580–2592. [36] Claire Le Goues, ThanhVu Nguyen, Stephanie Forrest, and Westley Weimer. 2012. GenProg: A Generic Method for Automatic Software Repair. IEEE Transactions on Software Engineering 38, 1 (2012). [37] Cheryl Lee, Chunqiu Steven Xia, Longji Yang, Jen-tse Huang, Zhouruixing Zhu, Lingming Zhang, and Michael R Lyu. 2025. UniDebugger: Hierarchical MultiAgent Framework for Unified Software Debugging. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing (EMNLP). 18248– 18277. [38] Kui Liu, Anil Koyuncu, Dongsun Kim, and Tegawendé F Bissyandé. 2019. TBar: Revisiting template-based automated program repair. In Proceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). 31–42. [39] Andrea Mangiatordi and Marco Lazzari. 2018. Combined use of artificial intelligence and crowdsourcing to provide alternative content for images on websites. In Proceedings of the 2018 15th IEEE Annual Consumer Communications & Networking Conference (CCNC). 1–6. [40] Forough Mehralian, Titus Barik, Jeff Nichols, and Amanda Swearngin. 2024. Automated Code Fix Suggestions for Accessibility Issues in Mobile Apps. arXiv preprint arXiv:2408.03827 (2024). [41] Forough Mehralian, Ziyao He, and Sam Malek. 2025. Automated Accessibility Analysis of Dynamic Content Changes on Mobile Apps. In Proceedings of the 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). 2689–2701. [42] Forough Mehralian, Navid Salehnamadi, Syed Fatiul Huq, and Sam Malek. 2022. Too much accessibility is harmful! automated detection and analysis of overly accessible elements in mobile apps. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering (ASE). 1–13. [43] Forough Mehralian, Navid Salehnamadi, and Sam Malek. 2021. Data-driven accessibility repair revisited: on the effectiveness of generating labels for icons in Android apps. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). 107–118.

[44] Xiangxin Meng, Zexiong Ma, Pengfei Gao, and Chao Peng. 2024. An empirical study on llm-based agents for automated bug fixing. arXiv preprint arXiv:2411.10213 (2024). [45] Peya Mowar, Yi-Hao Peng, Jason Wu, Aaron Steinfeld, and Jeffrey P Bigham. 2025. CodeA11y: Making AI Coding Assistants Useful for Accessible Web Development. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems. 1–15. [46] Hoang Duong Thien Nguyen, Dawei Qi, Abhik Roychoudhury, and Satish Chandra. 2013. Semfix: Program repair via semantic analysis. In Proceedings of the 2013 35th International Conference on Software Engineering (ICSE). 772–781. [47] OpenAI. 2025. o4-mini-2025-04-16. Retrieved Oct 01, 2025 from https://platform. openai.com/docs/models/o4-mini [48] OpenAI. 2025. text-embedding-3-small. Retrieved Oct 01, 2025 from https: //platform.openai.com/docs/models/text-embedding-3-small [49] Haifeng Ruan, Yuntong Zhang, and Abhik Roychoudhury. 2025. SpecRover: Code Intent Extraction via LLMs. In Proceedings of the 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). 963–974. [50] Navid Salehnamadi, Forough Mehralian, and Sam Malek. 2022. Groundhog: An automated accessibility crawler for mobile apps. In Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering (ASE). 1–12. [51] Letícia Seixas Pereira, João Guerreiro, André Rodrigues, Tiago Guerreiro, and Carlos Duarte. 2024. From Automation to User Empowerment: Investigating the Role of a Semi-automatic Tool in Social Media Accessibility. ACM Transactions on Accessible Computing 17, 3 (2024), 1–25. [52] Aditya Bharat Soni, Boxuan Li, Xingyao Wang, Valerie Chen, and Graham Neubig. 2025. Coding Agents with Multimodal Browsing are Generalist Problem Solvers. arXiv preprint arXiv:2506.03011 (2025). [53] Deque Systems. 2025. Axe accessibility testing tools are the best on the planet. Retrieved Oct 01, 2025 from https://www.deque.com/axe/ [54] Mahan Tafreshipour, Anmol Deshpande, Forough Mehralian, Iftekhar Ahmed, and Sam Malek. 2024. Ma11y: A Mutation Framework for Web Accessibility Testing. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). 100–111. [55] SWE-Bench Team. 2025. SWE-Bench Multimodal Leaderboard. https://www. swebench.com/index.html#multimodal. Accessed: 2025-10-23. [56] Trae Research Team, Pengfei Gao, Zhao Tian, Xiangxin Meng, Xinchen Wang, Ruida Hu, Yuanan Xiao, Yizhou Liu, Zhao Zhang, Junjie Chen, Cuiyun Gao, Yun Lin, Yingfei Xiong, Chao Peng, and Xia Liu. 2025. Trae Agent: An LLM-based Agent for Software Engineering with Test-time Scaling. (2025). arXiv:2507.23370 [57] WAI. 2025. Techniques for WCAG 2.2. Retrieved Dec 02, 2025 from https: //www.w3.org/WAI/WCAG22/Techniques/ [58] WAI. 2025. Understanding SC 1.1.1: Non-text Content (Level A). Retrieved Oct 01, 2025 from https://www.w3.org/WAI/WCAG22/Understanding/non-textcontent.html [59] WAI. 2025. Understanding SC 1.4.3: Contrast (Minimum) (Level AA). Retrieved Oct 01, 2025 from https://www.w3.org/WAI/WCAG22/Understanding/contrastminimum.html [60] WAI. 2025. Understanding SC 2.5.8: Target Size (Minimum) (Level AA). Retrieved Oct 01, 2025 from https://www.w3.org/WAI/WCAG22/Understanding/targetsize-minimum [61] WAI. 2025. Web Content Accessibility Guidelines (WCAG) 2.2. Retrieved Dec 02, 2025 from https://www.w3.org/TR/WCAG22/ [62] Yuxuan Wan, Chaozheng Wang, Yi Dong, Wenxuan Wang, Shuqing Li, Yintong Huo, and Michael Lyu. 2025. Divide-and-Conquer: Generating UI Code from Screenshots. Proceedings of the ACM on Software Engineering 2, FSE (2025), 2099–2122. [63] Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brennan, Hao Peng, Heng Ji, and Graham Neubig. 2025. OpenHands: An Open Platform for AI Software Developers as Generalist Agents. In The Thirteenth International Conference on Learning Representations. [64] WebAIM. 2025. The 2025 report on the accessibility of the top 1,000,000 home pages. Retrieved Oct 01, 2025 from https://webaim.org/projects/million/ [65] WebAIM. 2025. WAVE Web Accessibility Evaluation Tools. Retrieved Oct 01, 2025 from https://wave.webaim.org/ [66] Shaomei Wu, Jeffrey Wieland, Omid Farivar, and Julie Schiller. 2017. Automatic alt-text: Computer-generated image descriptions for blind users on a social network service. In Proceedings of the 2017 ACM Conference on Computer Supported Cooperative Work and Social Computing. 1180–1192. [67] Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. 2025. Demystifying llm-based software engineering agents. Proceedings of the ACM on Software Engineering 2, FSE (2025), 801–824. [68] Chunqiu Steven Xia, Zhe Wang, Yan Yang, Yuxiang Wei, and Lingming Zhang. 2025. Live-SWE-agent: Can Software Engineering Agents Self-Evolve on the Fly? arXiv preprint arXiv:2511.13646 (2025).

A11YRepair: Bridging Web Accessibility Barriers via Knowledge-Enhanced Divide-and-Conquer Repair

[69] Chunqiu Steven Xia and Lingming Zhang. 2022. Less training, more repairing please: revisiting automated program repair via zero-shot learning. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). 959–971. [70] Chunqiu Steven Xia and Lingming Zhang. 2024. Automated program repair via conversation: Fixing 162 out of 337 bugs for $0.42 each using chatgpt. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). 819–831. [71] Boyang Yang, Zijian Cai, Fengling Liu, Bach Le, Lingming Zhang, Tegawendé F Bissyandé, Yang Liu, and Haoye Tian. 2025. A Survey of LLM-based Automated Program Repair: Taxonomies, Design Paradigms, and Applications. arXiv preprint arXiv:2506.23749 (2025). [72] John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. Swe-agent: Agent-computer interfaces enable automated software engineering. Advances in Neural Information Processing Systems 37 (2024), 50528–50652. [73] John Yang, Carlos E Jimenez, Alex L Zhang, Kilian Lieret, Joyce Yang, Xindi Wu, Ori Press, Niklas Muennighoff, Gabriel Synnaeve, Karthik R Narasimhan, Diyi Yang, Sida Wang, and Ofir Press. 2025. SWE-bench Multimodal: Do AI Systems Generalize to Visual Software Domains?. In The Thirteenth International Conference on Learning Representations. [74] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R Narasimhan, and Yuan Cao. 2023. React: Synergizing reasoning and acting in language models. In The eleventh International Conference on Learning Representations. 1–33. [75] He Ye, Aidan ZH Yang, Chang Hu, Yanlin Wang, Tao Zhang, and Claire Le Goues. 2025. AdverIntent-Agent: Adversarial Reasoning for Repair Based on Inferred Program Intent. Proceedings of the ACM on Software Engineering 2, ISSTA (2025), 1398–1420.

[76] Quanjun Zhang, Chunrong Fang, Yang Xie, YuXiang Ma, Weisong Sun, Yun Yang, and Zhenyu Chen. 2024. A systematic literature review on large language models for automated program repair. arXiv preprint arXiv:2405.01466 (2024). [77] Quanjun Zhang, Chunrong Fang, Tongke Zhang, Bowen Yu, Weisong Sun, and Zhenyu Chen. 2023. Gamma: Revisiting template-based automated program repair via mask prediction. In Proceedings of the 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). 535–547. [78] Xiaoyi Zhang, Anne Spencer Ross, and James Fogarty. 2018. Robust annotation of mobile application interfaces in methods for accessibility repair and enhancement. In Proceedings of the 31st Annual ACM Symposium on User Interface Software and Technology. 609–621. [79] Yuxin Zhang, Sen Chen, Lingling Fan, Chunyang Chen, and Xiaohong Li. 2023. Automated and context-aware repair of color-related accessibility issues for android apps. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). 1255–1267. [80] Yuxin Zhang, Sen Chen, Xiaofei Xie, Zibo Liu, and Lingling Fan. 2025. ScenarioDriven and Context-Aware Automated Accessibility Testing for Android Apps. In Proceedings of the 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). 2777–2789. [81] Yuntong Zhang, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. 2024. Autocoderover: Autonomous program improvement. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). 1592–1604. [82] Mingyuan Zhong, Xia Chen, Davin Win Kyi, Chen Li, James Fogarty, and Jacob O Wobbrock. 2025. TaskAudit: Detecting Functiona11ity Errors in Mobile Apps via Agentic Task Execution. arXiv preprint arXiv:2510.12972 (2025).

A11YRepair: Bridging Web Accessibility Barriers via Knowledge-Enhanced Divide-and-Conquer Repair

Related documents