Characterizing Visual Accessibility Issues in AI Developer Tools: An Empirical Study

Characterizing Visual Accessibility Issues in AI Developer Tools: An Empirical Study Sabrina Haque

Christoph Csallner

Department of Computer Science and Engineering University of Texas at Arlington Arlington, Texas, USA sxh3912@mavs.uta.edu

Department of Computer Science and Engineering University of Texas at Arlington Arlington, Texas, USA csallner@uta.edu

arXiv:2608.05116v1 [cs.SE] 5 Aug 2026

Abstract AI-assisted developer tools increasingly mediate programming through chat panels, terminal agents, generated diffs, and streaming status output. These interaction surfaces may create visual accessibility barriers for blind, low-vision, and color-vision-deficient developers, yet little is known about how such barriers are reported in public tool ecosystems. We analyze issues and forum discussions from five AI developer tool ecosystems: GitHub Copilot in VS Code, Cursor, Claude Code, OpenAI Codex, and OpenCode. From 2,652 keyword-retrieved candidates, a three-model ensemble identified 600 unanimously positive visual accessibility reports. A stratified manual sanity check supported this conservative selection. Topic modeling and qualitative analysis identified three recurring categories: screen-reader and assistive-technology barriers; visual presentation, contrast, and differentiation problems; and readability, scaling, and control limitations in AI-specific interfaces. The relative prominence of these concerns varied across ecosystems and reflected differences in editor, terminal, chat, diff, and agent interaction surfaces. An exploratory metadata analysis further identified differences in reporter activity and, across the GitHub-based ecosystems, maintainer participation and closure processes. These findings show that the accessibility record of AI developer tools is shaped by both their interaction design and the reporting and maintenance practices of their surrounding ecosystems. ACM Reference Format: Sabrina Haque and Christoph Csallner. 2026. Characterizing Visual Accessibility Issues in AI Developer Tools: An Empirical Study. In Proceedings of MSR ’26: Proceedings of the 23rd International Conference on Mining Software Repositories (MSR 2026). ACM, New York, NY, USA, 10 pages. https://doi.org/XXXXXXX.XXXXXXX

1

Introduction

The rapid integration of generative AI has led to a shift in the software development landscape. Developers now use tools such as GitHub Copilot [20] and Cursor [16] to write code, explain programs, debug errors, and modify existing projects [25]. These tools provide chat panels, inline assistance, terminal command execution, and act as semi-autonomous agents that work directly inside the editor or terminal [45]. Rather than writing and executing code Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s). MSR 2026, Rio de Janeiro, Brazil © 2026 Copyright held by the owner/author(s). ACM ISBN 978-x-xxxx-xxxx-x/YYYY/MM https://doi.org/XXXXXXX.XXXXXXX

directly, developers increasingly guide AI through natural language prompts and iteratively refine AI-generated outputs [10, 36]. This shift creates new opportunities for software development, but it also raises an important question: whether these emerging AI-assisted tools are usable and accessible for all developers. Visual accessibility concerns whether interfaces can be perceived, understood, and used by people with visual impairments, including blindness, low vision, and color-vision deficiency. Programming environments are already difficult to use with screen readers [30]. Visually impaired developers often face barriers in code navigation, debugging, and collaborative software work [3]. Recent studies show that generative AI can help by supporting debugging, explaining code, describing visual materials, and reducing dependence on sighted colleagues [12]. However, the same tools can also introduce new risks, including inaccessible interfaces, auditory overload, and difficulty interpreting generated outputs [18, 43]. These challenges become especially important because AI coding tools introduce dynamic content, such as real-time code generation and streaming responses, along with complex interactions that traditional accessibility practices may not fully address [13]. If the interfaces around AI assistance are not accessible, a tool meant to speed developers up can instead slow them down or exclude them from emerging software-development workflows. As AI coding tools become basic infrastructure for software work, their accessibility must be treated as a core requirement rather than a secondary usability concern. Accessibility problems in AI tools are not hypothetical [1]. A preliminary screen reader evaluation of ChatGPT, Copilot, Gemini, and Perplexity found usability difficulties across tools, especially in navigation structure, labeling, feedback mechanisms, and prompt handling [24]. Similar tension exists in coding and developer tools. Recent studies of screen reader users and AI coding assistants found that these tools can empower users, but users still struggle to communicate intent, review generated output, switch between views, and retain control [13, 18]. These studies provide deep insight into user experience through interviews, controlled tasks, and expert evaluation. However, they do not show how visual accessibility problems surface in the public maintenance channels where AI developer tools evolve. Issue trackers and discussion forums capture bug reports, feature requests, accessibility testing findings, and user discussions as problems are encountered in practice. Mining these artifacts has already proven useful for studying accessibility gaps in software projects and developer communities [4, 11]. However, existing mining work has largely focused on general software, mobile apps, or broad accessibility discussions. To our knowledge, no prior mining study has focused on visual accessibility reports in AI developer tools. This

MSR 2026, April 2026, Rio de Janeiro, Brazil

gap matters because AI developer tools introduce interaction surfaces that differ from traditional editor, web, or mobile interfaces, including chat panels, streaming responses, generated diffs, terminal transcripts, and agent status updates. In this work, we study visual accessibility reports from five popular AI developer-tool ecosystems. We selected these ecosystems to represent different primary interaction environments and because each provides a public channel through which users report problems. GitHub Copilot in VS Code [20] represents editorintegrated AI assistance. GitHub Copilot is the most widely adopted AI coding assistant, with over 20 million cumulative users [46], and is deeply integrated into VS Code, the most widely used code editor [41]. Cursor represents an AI-native code editor and has grown to over one million daily active users [44]. Claude Code [14] and OpenCode [34] prominently support terminal-oriented agent workflows, whereas OpenAI Codex spans command-line, desktop, and editor interfaces [32]. These descriptions refer to the primary interaction environments represented by these tools but several tools support multiple interfaces. OpenCode is an open-source coding agent with over 184k GitHub stars [34] and 23k forks, and its public development process allows us to observe how accessibility concerns are raised and addressed in a community-maintained project. The AI developer-tool landscape is large and evolving quickly; together, these ecosystems provide a diverse view of accessibility concerns across prominent editor-integrated, AI-native, terminaloriented, and multi-interface development environments. We mined bug reports and forum discussions from each tool’s own public maintenance channels. For Claude Code, OpenAI Codex, and OpenCode, we collected GitHub issues.123 GitHub Copilot does not maintain a separate public issue tracker, so we queried the VS Code repository4 for issues mentioning Copilot created after its public launch in June 2021. Cursor does not use a public GitHub issue tracker for user reports, so we collected threads from the official Cursor community forum.5 We included all reports created on or before June 15, 2026. We used each tool’s public issue tracker or official forum because these channels record problems reported directly to maintainers. Using a mixed-method analysis, we characterize the visual accessibility concerns surfaced across these tools’ public ecosystems. We mainly ask two research questions: • RQ1: What types of visual accessibility issues are reported in the public channels of AI-assisted developer tools? • RQ2: How do the nature and response patterns of reported visual accessibility barriers vary across AI developer tool ecosystems?

2

Methodology

To answer our research questions, we conducted a mixed-methods empirical study of visual accessibility reports from public AI developertool ecosystems. Figure 1 summarizes the study pipeline. We collected reports from the five ecosystems (GitHub Copilot in VS Code [20], Cursor [16], Claude Code [14], OpenAI Codex [32], 1 https://github.com/anthropics/claude-code 2 https://github.com/openai/codex 3 urlhttps://github.com/anomalyco/opencode 4 https://github.com/microsoft/vscode 5 https://forum.cursor.com/

Sabrina Haque and Christoph Csallner

and OpenCode [34]) as introduced earlier, which represent editorintegrated, AI-native, terminal-oriented, and multi-interface development environments. We then used BERTopic [22] and qualitative analysis to identify recurring accessibility barriers and compare their distribution across tool ecosystems. For RQ2, we additionally used issue metadata collected with the reports to examine reporter activity and repository-level response patterns.

Figure 1: Overview of the study methodology

2.1

Data Collection and Preprocessing

We collected public reports created on or before June 15, 2026. For GitHub Copilot in VS Code, Claude Code, OpenAI Codex, and OpenCode, we collected publicly available GitHub issues through the GitHub REST API [21]. We retrieved issues regardless of state and retained the title, body, labels, state, reporter, creation date, comments, comment-author associations, closure time, closure actor, and closure reason when available. GitHub Copilot does not maintain a separate public issue tracker. We therefore queried the VS Code repository for issues containing the term copilot that were created after Copilot’s public launch in June 2021. After accessibility candidate retrieval, we manually reviewed the retained reports to exclude issues that mentioned Copilot but concerned general VS Code behavior rather than Copilot functionality. Cursor likewise does not use a public GitHub issue tracker for user reports. We collected public threads returned by searches of the Cursor community forum [15], retaining each thread’s title, body, tags, reply count, and creation date. Forum search served only to identify potential reports; all retrieved threads underwent the same cleaning and validation procedure as the GitHub issues. We implemented the entire data-processing pipeline in Python. Before candidate retrieval, we removed duplicate issue reports and reports with no body text. Our analysis was limited to issue reports and excluded pull requests. We removed non-English reports using the langdetect [37] library. We then cleaned the title and body text using regular-expression-based preprocessing. This process removed URLs, email addresses, user mentions, HTML tags, code

Characterizing Visual Accessibility Issues in AI Developer Tools: An Empirical Study

blocks, inline code, Markdown formatting, quoted text, embedded links and images, and configuration tables or boilerplate commonly included in issue templates. We normalized whitespace and converted the remaining text to lowercase. These steps ensured that keyword matching in the subsequent step operated on the natural language content of each issue rather than on code, metadata, or formatting artifacts [40].

2.2

Keyword-Based Candidate Retrieval

The full collection across five tools contains a large volume of reports on topics unrelated to accessibility, including functional bugs, feature requests, performance concerns, and documentation questions. Rather than validating every report with a language model, which would be costly and wasteful at this scale, we used keyword-based retrieval as a first-pass filter. This step discarded offtopic content cheaply and reproducibly, leaving a smaller candidate pool of potentially visual-accessibility-related reports. Keywordbased filtering is a well-established first step in mining studies of accessibility reports, which commonly use lexical retrieval to construct candidate sets before finer-grained classification [31]. We developed the keyword set by drawing on prior empirical studies of accessibility discussions in developer communities and issue trackers [4, 11, 23]. Rather than using a flat list, we organized the keywords into semantic groups: General accessibility: accessibilit*, a11y, no accessible, not accessible, inaccessible, disabilit* Visual impairment: blind, low vision, visually impaired, vision impaired, vision impairment, visual impairment Assistive technology or rules: screen reader, screen-reader, screenreader, nvda, jaws, voiceover, voice over, voice access, assistive technology, braille, wcag, section 508 Labeling and alt text: aria, aria-label, accessible name, accessible label, alt text, alternative text, alt-text, content description Visual presentation: contrast, color contrast, color blind, colorblind, font size We used wildcard matching for the stemmed terms accessibilit* and disabilit* to capture morphological variants. Matching was case-insensitive and applied to the cleaned title and body of each report. We performed keyword retrieval only after cleaning the reports. Raw issue and forum content often contains code blocks, issue templates, copied logs, etc. which may include accessibility-related terms, unrelated to the reporter’s actual concern. For example, an issue template may contain a generic accessibility field, while a code snippet may include an aria-label attribute unrelated to the reported problem. Applying keyword matching after cleaning is aimed to reduce this noise. Cleaning alone could not eliminate all false positives. Terms such as contrast, blind, and accessible may still be used in other contexts. We therefore treated the retrieved reports as candidates for further validation. This process produced 2,652 candidate reports across the five tool ecosystems (Table 1, column “N”).

MSR 2026, April 2026, Rio de Janeiro, Brazil

2.3

LLM-Based Validation

The keyword retrieval step identified reports that potentially concerned visual accessibility, but it could not determine whether accessibility was the reporter’s actual concern. Since manual annotation was not feasible at this point, we opted for an LLM-based approach. Recent work suggests that LLMs can support qualitative software engineering research, but should be assessed through agreement and validation procedures [2, 9]. We therefore used an ensemble of three large language models to validate the retrieved candidates and annotate whether each report described a visual or screen-reader accessibility barrier. Each model received the same structured prompt containing the cleaned issue title and body. The prompt defined visual accessibility issues using explicit inclusion and exclusion criteria grounded in prior accessibility research [4, 30]. Listing 1 presents the complete prompt. We selected GPT-5-mini [33], Gemini 2.5 Flash [19], and Llama 3.3 70B [28] to include models from different providers and model families. Using multiple models reduced risk of model-specific biases and enabled us to assess the consistency of the resulting annotations. Each model returned a structured JSON response containing a three-way label (yes, no, or uncertain), a binary accessibility flag and a list of key terms. Following prior work, we also included a confidence score from 0 to 100 and a brief rationale to make the model outputs easier to inspect and interpret [17]. The rationale helped record the basis for each classification, while the confidence score captured the model’s self-reported certainty. Across the 2,652 keyword-retrieved candidates, all three models agreed on the binary label for 2,239 reports (84.4%). The ensemble produced 600 unanimously positive reports and 1,639 unanimously negative reports; the remaining 413 reports received mixed labels. To assess how consistently the models applied the classification criteria, we computed inter-model agreement using Cohen’s kappa for each pair of models [26]. The pooled pairwise Cohen’s 𝜅 values ranged from 0.75 to 0.76, which falls in the substantial-agreement range, indicating that the three models applied the accessibility criteria consistently despite coming from different model families. Table 1 summarizes the agreement and retained reports by tool ecosystem. We retained only the 600 unanimously positive reports as a conservative high-confidence set for thematic analysis. Some relevant reports may have been excluded when one model was uncertain or disagreed, but the retained set provides a stronger basis for analyzing recurring issue types. Manual validation of all 2652 issues across 5 repositories was not feasible, so we conducted a stratified manual sanity check to assess whether the ensemble’s labels aligned with human judgment. We sampled 100 reports across the five tool ecosystems: 50 unanimously positive reports, 25 unanimously negative reports, and 25 reports for which the models disagreed. The sample included 20 reports from each ecosystem and was balanced across the three agreement conditions. Each report was reviewed manually without access to the model labels and assigned one of three labels: yes, no, or uncertain.

MSR 2026, April 2026, Rio de Janeiro, Brazil

Sabrina Haque and Christoph Csallner

Table 1: Inter-model agreement and high-confidence visual accessibility reports by tool ecosystem. N = issues per repository after keyword-based filtering; GPT = GPT-5-mini, Gemini = Gemini 2.5 Flash, Llama = Llama 3.3 70B. “Uncertain” labels are treated as “No”. Agr. = percentage of issues for which all three models produced the same binary label; Unan. = issues unanimously labeled yes or no; 𝜅 = Cohen’s Kappa; Combined 𝜅 values are pooled across repositories. “Yes” Tool

Unan.

N GPT Gemini Llama Agr. (%) Yes

Cohen’s 𝜅

No GPT–Gem. GPT–Llama Gem.–Llama

VS Code Copilot 309 Claude Code 1430 OpenAI Codex 318 OpenCode 215 Cursor Forum 380

142 308 92 67 102

180 412 112 84 139

177 319 85 67 116

72.5 122 87.7 263 84.0 71 85.6 57 81.6 87

102 991 196 127 223

0.76 0.76 0.77 0.77 0.71

0.52 0.79 0.76 0.80 0.76

0.62 0.78 0.72 0.79 0.69

Combined

711

927

764

84.4 600 1639

0.76

0.75

0.75

2652

Listing 1: Prompt template used for LLM-based classification. You are a software developer and accessibility researcher analyzing GitHub issues from AI coding tools. Your task is to determine whether the issue is specifically about vision-related accessibility. Definition: An issue is vision-accessibility-related if it concerns barriers affecting blind, low-vision, color-blind, or visually impaired users. This includes: - Screen reader or assistive technology problems (e.g., NVDA, JAWS, VoiceOver, Narrator) - Missing or incorrect accessible names, labels, ARIA, roles, semantic structure , or announcements - Color contrast, high-contrast mode, dark/light theme readability, or coloronly information affecting accessibility - Font size, zoom, layout readability, or visual clarity when it concerns accessibility barriers for low-vision users - Focus visibility or focus behavior when it affects accessibility, screen reader use, or low-vision users - Accessibility of AI-generated output (chat responses, streaming text, terminal output, progress indicators, diffs, status messages) when it affects screen reader or low-vision users Exclude: - General keyboard shortcut bugs with no visual or screen-reader accessibility impact - General UI bugs, layout preferences, or theme requests that do not specifically concern visual accessibility - General terminal bugs unless the issue concerns screen reader access, contrast , ANSI/color output, spinners, or visual accessibility - Feature requests unrelated to vision or screen-reader accessibility - Issues where accessibility is mentioned only in unrelated boilerplate or templates Issue Title: {title} Issue Body: {body} Respond with ONLY a valid JSON object. Do not include markdown or extra text. Use this schema: { "label": "yes" | "no" | "uncertain", "is_visual_or_screen_reader_accessibility": true | false, "confidence": 0-100, "key_terms": ["term1", "term2"], "reasoning": "Brief explanation in one sentence." } Rules: - Use "yes" only when the issue clearly concerns visual or screen-reader accessibility. - Use "no" when the issue is clearly unrelated. - Use "uncertain" when the issue may be accessibility-related but lacks enough evidence. - Set is_visual_or_screen_reader_accessibility to true only for "yes"; otherwise false. - Keep reasoning brief.

Among the 50 unanimously positive reports, 47 were judged visual-accessibility related, two were judged uncertain, and one

was judged unrelated. All 25 unanimously negative reports were judged unrelated. The disagreement sample was mixed: 11 reports were judged related, 13 unrelated, and one uncertain. These results support the use of unanimous positive agreement as a conservative selection criterion. They also show that the reports on which the models disagreed were genuinely ambiguous rather than straightforward cases that the ensemble failed to classify consistently.

2.4

Thematic Clustering and Qualitative Analysis

We used BERTopic [22] to organize the high-confidence reports into recurring thematic groups before conducting qualitative analysis. BERTopic was suitable for this task because the reports were relatively short, varied in wording across tool ecosystems, and often used to find themes in similar online discussions [35]. The method combines sentence embeddings with density-based clustering and class-based TF-IDF representations, allowing semantically related reports to be grouped while retaining interpretable topic terms [27, 38]. We applied BERTopic to the cleaned title and body text of the 600 high-confidence reports. We used all-mpnet-base-v2 to generate embeddings and set the minimum topic size to 15. This threshold reduced the likelihood of treating small, isolated groups of reports as meaningful themes. We treated the clustering output as an exploratory structure rather than a final taxonomy. The purpose of clustering was to identify candidate thematic groupings that could be examined and interpreted through manual analysis. BERTopic produced three non-outlier clusters containing 262, 215, and 90 reports, respectively. The remaining 33 reports were assigned to BERTopic’s outlier topic. To interpret and characterize each cluster, we manually reviewed 50 randomly selected reports from each cluster, resulting in a qualitative sample of 150 reports. Sampling was stratified by tool ecosystem. For each sampled report, we recorded the primary accessibility barrier, the interaction surface where it occurred, and a finer-grained subtheme via inductive coding. Table 2 presents representative top terms for each cluster and the labels we assigned after reviewing sampled reports.

Characterizing Visual Accessibility Issues in AI Developer Tools: An Empirical Study

MSR 2026, April 2026, Rio de Janeiro, Brazil

Table 2: BERTopic clusters and qualitative interpretations (𝑁 = 600 unanimously classified accessibility reports). Top terms are shown after preprocessing and are used only to summarize the automatically derived clusters.

interaction options so that developers using assistive technologies can access the tool’s full functionality. Another concern was the gap between reading AI output and acting on it. Reports described inline suggestions that were visible but not exposed to NVDA, chat responses without headings or landmarks, and code blocks without clear labels or group information. These gaps made it difficult to find the latest response, distinguish suggestions, or move through long conversations. One NVDA user reported: “Multiple accessibility problems when using a screen reader (NVDA). The main one is that is is impossible to navigate to the last response. reading up from the input field using NVDA browse mode jumps far back in the chat responses. reading down from there does show later entries in the chat, but there’s no easy way to get to the last response without going line by line.” 6 Generated output also needed to remain actionable, not merely readable. One report described an Accessible View in which a user could reach a generated code block but could not complete the next step of inserting it into the editor: “This is not currently supported and users have to close the Accessible View and manually relocate to the codeblock.” 7 Thus, access to generated text alone was insufficient. Developers also needed to reach the actions associated with that output from the accessible representation. Terminal-based agents raised another set of concerns because their status changes while the model is working. Reports described spinners, streaming text, and repeated redraws that produced confusing speech, skipped lines, interrupted reading, or moved the terminal viewport. One visually impaired user explained: “I am visually impaired and operate the terminal app using Apple’s VoiceOver screen reader...At present there doesn’t seem to be a way to know when it has finished generating a response. As a result, I periodically copy the terminal output into another text editor and have it read aloud to check for any differences.” 8 Other sampled reports described animated status labels that generated unhelpful speech output, redraws that moved the terminal viewport away from earlier content, and streaming behavior that caused screen readers to freeze or skip lines. A smaller set of reports requested read-aloud responses and built-in voice access.

Cluster

Reports Representative terms

0

262

1

215

2

90

Outliers

33

3

top

Qualitative interpretation

screen, accessibility, reader, screen reader, chat, version theme, color, dark, terminal, contrast, background font, size, font size, chat, settings, ui —

Screen reader and assistive technology Visual presentation, contrast, and differentiation Readability, scaling, and interface control Reports not assigned to a stable topic

Findings

We use the three clusters and our qualitative analysis of sampled reports to answer RQ1 by characterizing the visual accessibility barriers reported across AI developer tools. We then answer RQ2 by comparing how these barriers are distributed across the five tool ecosystems.

3.1

RQ1: Types of Reported Visual Accessibility Barriers

Our qualitative analysis of the three BERTopic-derived clusters identified three recurring categories of visual accessibility barriers: (1) screen reader and assistive technology barriers, (2) visual presentation, contrast, and differentiation problems, and (3) readability, scaling, and control limitations in AI-specific interfaces. The following subsections explain how these barriers manifested in the sampled reports and the interaction surfaces where they occurred. 3.1.1 Screen Reader and Assistive Technology. The largest cluster (262 reports) concerns screen-reader and assistive-technology access. In manually analyzed reports, most entries involved screen readers, including NVDA, JAWS, VoiceOver, Narrator, and ORCA. A smaller set raised voice access, text-to-speech, keyboard-focus, or motion-related concerns. Users were concerned with accessing different points in an AI-assisted workflow, such as configuring a request, working with generated output, and monitoring an agent while it runs. A recurring concern involved AI-specific controls. Reports described prompt fields whose commands or context options were not announced, model selectors whose current or expanded state was unclear, and dialogs whose keyboard focus moved away before users could reach permission or action controls. For example, one Copilot accessibility report noted that NVDA did not announce the inline-chat placeholder, which described options for adding context, accessing extensions, and invoking commands. Other reports identified inconsistent shortcuts for adding context across chat surfaces and action buttons that appeared only on hover. The latter also created a barrier for voice access because a button that is not discoverable cannot be invoked. These reports show that AI controls must clearly expose available commands, state, and

3.1.2 Visual Presentation, Contrast, and Differentiation. The second cluster (215 reports) concerns the visual presentation of AI-specific interfaces. In the manual sample, reports described low-contrast text, weak visual separation between different types of content, and limited control over colors and themes. These problems appeared in chat panels, terminal transcripts, agent lists, tool output, and generated diff views. A recurring concern involved text or highlights that became difficult or impossible to read under particular terminal or editor themes. Reports described syntax-highlighted code, tool results, 6 https://github.com/openai/codex/issues/26491 7 https://github.com/microsoft/vscode/issues/199119 8 https://github.com/openai/codex/issues/150

MSR 2026, April 2026, Rio de Janeiro, Brazil

selected items, links, and approval dialogs whose foreground and background colors had insufficient contrast. In some cases, text was present but could only be read after selecting it: “Kotlin annotations in code blocks are rendered in a color that is identical or nearly identical to the background on dark terminal themes. The text is present (visible when selecting/highlighting) but completely unreadable without intervention.” 9 These cases were not limited to a single appearance mode. They included light themes in which text inherited a light foreground, dark terminal themes in which syntax-highlighted code blended into the background, and high-contrast editor themes in which inline AI content remained invisible. A related set of reports concerned the lack of control over these visual encodings. AI developer tools often introduce their own colors for prompts, tool calls, agent names, status messages, and diffs. When these colors are hardcoded or only partly inherit the host theme, users cannot adapt the interface to their visual needs. Sampled reports requested configurable foreground and background colors, theme-aware rendering, and color schemes that respect terminal palettes. Many reports also requested theme customization or compatibility with existing terminal and editor settings. Diff rendering was a particularly common example. Muted colors might blend with syntax highlighting, making added and removed lines harder to inspect while hardcoded bright colors could clash with dark terminals and cause visual fatigue during long review sessions. Some reports requested a minimal diff mode that used non-background indicators, such as line markers or line numbers, rather than relying on large blocks of fixed color. One feature request from a colorblind developer stated: “I would like to suggest / request adding Colorblind Theme / Mode to the Web / Desktop app. My main pain as a Colorblind is distinguishing between the Add / Removed lines in the Diff View.” 10 Another pattern involved weak visual distinction between the parts of an AI interaction. In long chat or terminal sessions, user prompts, assistant responses, tool output, and agent status lines could use nearly identical styling. This made it difficult to find a previous instruction, identify the source of a message, or follow the flow of an extended interaction: “User prompts and assistant responses are currently rendered with very little visual distinction in the main conversation flow. At the moment, this makes long sessions harder to scan, especially when looking back through a discussion to find a previous user instruction.” 11 These reports show that visual hierarchy is especially important in AI-assisted tools, where developers must repeatedly separate their own instructions from generated responses, tool activity, and proposed changes. 3.1.3 Readability, Scaling, and Control. The third cluster (90 reports) concerns the readability and customization of AI-specific interfaces. In the manual sample, most reports involved font size,

Sabrina Haque and Christoph Csallner

zoom, typography, and small interface elements. Others concerned dense layouts and weak hierarchy in long AI-generated responses. These issues appeared in chat panels, plan views, terminal output, agent windows, and generated code or documentation. The most common concern was that AI panels did not provide independent control over text size or typography12 . Reports described chat text that was smaller than the editor text, fixed font families that were hard to read, and AI panels that ignored system or editor font settings. In many cases, the only workaround was to zoom the entire application. This changed the rest of the workspace even when developers only needed larger text in the chat or agent panel. One feature request described the impact on a developer with astigmatism: “The default font it responds with is too small and blurry for my astigmatism. It needs to be better for vision because my vision isn’t that bad. I know many developers with far worse vision than me, and if I’m struggling to read the output then it’s nearly inaccessible to them.” 13 Several reports showed that enlarging text could create a second problem. Global zoom could hide tooltips or controls, crop overlays, or reduce the usable space for code and conversation. Large fonts also made fixed headers, decorative elements, and multi-line status areas consume much of a terminal or chat viewport. One visually impaired user explained: “I use very large fonts and it compresses down the scroll area a lot when there is a lot of text at the top.” 14 The report requested a compact layout that could hide decorative elements and preserve space for the conversation. These cases show that supporting larger text requires responsive layouts, not only a font-size setting. Another pattern concerned the readability of long AI-generated responses. Chat interfaces often present plans, summaries, and stepby-step instructions using Markdown headings and lists. However, reports described headings that were visually indistinguishable from body text, fixed line height and paragraph spacing that made responses look like dense walls of text, and truncated agent names that made it hard to identify the active agent. One report stated: “All markdown headings (h1–h6) rendered inside chat messages are visually identical to body text.” 15 When response hierarchy is not visible, developers must scan long generated text line by line to locate plans, decisions, or next steps. This is particularly problematic in AI-assisted workflows, where generated responses often serve as the main place for explaining actions, presenting alternatives, and summarizing work.

3.2

RQ2: Nature and Response Patterns of Reported Visual Accessibility Barriers Across Tools

RQ2 combines three sources of evidence. Figure 2 uses the 567 reports assigned to the three substantive BERTopic clusters to compare the distribution of barrier categories across tools. The 12 https://forum.cursor.com/t/font-size-in-chat/56747

9 https://github.com/anthropics/claude-code/issues/24807

13 https://github.com/anthropics/claude-code/issues/44248

10 https://github.com/anomalyco/opencode/issues/14755

14 https://github.com/anomalyco/opencode/issues/2750

11 https://github.com/openai/codex/issues/17879

15 https://github.com/anomalyco/opencode/issues/30542

Characterizing Visual Accessibility Issues in AI Developer Tools: An Empirical Study

Figure 2: Distribution of visual accessibility issue types across AI developer tools; shows the distribution of the 567 reports assigned to one of the three BERTopic clusters. Thirty-three reports assigned to the outlier topic are excluded. Percentages below 3% are not labeled.

remaining 33 reports were excluded from this comparison because BERTopic did not assign them to a coherent cluster. However, they were included in the metadata analyses because their outlier status reflects topic assignment rather than report validity. These distributions indicate which barriers were most visible in each tool’s public reports. Our interpretation of the variation across tools draws on the 150 manually reviewed reports used in RQ1. We also use issue metadata from all 513 reports in the four GitHub-based ecosystems to examine comments, maintainer participation, issue status, and closure patterns. Cursor is excluded from the response analysis because forum threads do not provide issue states, closure records, or author-association metadata directly comparable to GitHub. These measures describe visible activity in the repositories and do not indicate whether a reported barrier was fixed. We classified accounts as bots when the login included a bot marker, such as a “[bot]” suffix. We treated comments from accounts with the OWNER, MEMBER, or COLLABORATOR association as maintainer participation. 3.2.1 Nature of Reported Barriers. VS Code Copilot reports were dominated by screen-reader and assistive-technology barriers (92%). These reports were concentrated in editor-integrated AI surfaces, including Copilot Chat, Quick Chat, inline chat, suggestions, and Accessible View. Users described difficulty determining the state of model and context controls, locating a newly generated response, and moving from an accessible representation of generated code to the action needed to apply it. The key challenge was whether a developer could maintain a continuous workflow across the editor, chat, and generated output. In contrast, Claude Code and OpenCode contained the largest shares of visual-presentation and contrast related reports (55% and 54%, respectively). Many of these reports concerned terminaloriented interactions. In terminal-based agents, AI responses, tool output, and diffs are rendered within a developer’s existing terminal environment. Reports therefore focused on fixed foreground colors, hardcoded diff backgrounds, and incomplete support for terminal themes. These choices could make text difficult to read and could blur the distinction between prompts, responses, and code changes. Cursor showed a different pattern. Readability, scaling, and interface control accounted for the largest share of its clustered reports

MSR 2026, April 2026, Rio de Janeiro, Brazil

(40%), followed closely by visual-presentation concerns (38%). Reports frequently concerned the chat and agent panel inside the code editor. Users described text that was too small, and settings that did not provide independent control over AI-panel appearance. Several reports also suggested that the font-size controls were difficult to find, did not reliably affect the chat surface, or required an extension 16 . A frequent workaround was to zoom the entire application, even though this could reduce usable workspace or introduce additional layout problems. OpenAI Codex showed a more balanced distribution across the three categories. This pattern is consistent with its mixed interaction environment, which includes command-line and terminal interfaces, a desktop application, and an editor extension. Reports spanned screen-reader access to dynamic terminal output, contrast and visual distinction in conversations and diffs, and scaling problems in desktop and extension-based interfaces. Rather than concentrating in one surface, Codex reports reflected accessibility dependencies that moved with developers across these connected environments. 3.2.2 Response Patterns. As an exploratory analysis, we examined the repository level response metrics for our issue dataset. The 122 VS Code Copilot issues in our dataset came from 57 unique reporters, an average of 2.14 reports per reporter. Its five most active reporters contributed 44.3% of the reports. In comparison, other tools averaged between 1.04 and 1.08 reports per reporter, and their five most active reporters contributed between 7.2% and 14.0% of reports. The Copilot pattern may reflect sustained accessibility testing or reporting by a small group of contributors, although more information about their roles and reporting practices would be needed to interpret this pattern. Table 3 summarizes response patterns in the four GitHub repositories. Approximately 87% of Copilot and Claude Code reports were closed, compared with 84.2% of OpenCode reports and 33.8% of Codex reports. However, the closure processes differed. Human accounts closed most Copilot reports, whereas automated accounts closed 73.8% of all Claude Code reports. OpenCode closures were more evenly divided between bot and human accounts, while all Codex closures were performed by human accounts. Here, a human closure refers to closure by any non-bot account and does not necessarily indicate maintainer involvement. We also looked into the stated reason of closure. Among closed reports, 66.7% of Codex reports, 66.0% of Copilot reports, and 58.3% of OpenCode reports were marked as completed, compared with 11.3% of Claude Code reports. A completed closure, however, does not establish that the reported accessibility barrier was actually fixed. Non-bot comments appeared on 77.9% of Copilot reports, 57.7% of Codex reports, 54.4% of OpenCode reports, and 46.8% of Claude Code reports. Maintainer-associated accounts participated in 66.4% of Copilot reports, compared with 19.3% for OpenCode, 4.2% for Claude Code, and 2.8% for Codex. Human closures generally occurred sooner than automated closures. The median time to human closure was 0.3 days for Claude Code, 3.7 days for OpenCode, 4.6 days for Copilot, and 24.8 days for 16 https://forum.cursor.com/t/how-can-i-increase-the-font-size-in-the-chatwindow/23379/18

MSR 2026, April 2026, Rio de Janeiro, Brazil

Codex. Median bot-closure times were 29.4 days for Claude Code, 62.2 days for Copilot, and 77.7 days for OpenCode. These longer times may reflect inactivity-based automation, although we did not analyze the automation rules used by each repository. These measures primarily describe repository level patterns for our issue dataset, rather than the quality of accessibility remediation. Overall, the tools differed not only in the barriers visible in their reports, but also in how reporting was distributed across contributors and how the issue reports were handled.

4

Discussion

Recent user studies show that visually impaired developers can struggle to review generated changes, move between views, and follow agent activity during AI-assisted programming[13, 18]. Our study adds a maintenance-facing perspective by showing how these broader workflow difficulties appear in public issue trackers and forums across different tools. In our dataset, editor-integrated reports more often surfaced screen-reader and semantic-access barriers. Terminal-oriented ecosystems showed larger shares of contrast and visual-presentation concerns, while reports from AI panels more often involved text size, scaling, and independent customization. Screen-reader accessibility needs to extend beyond the host editor or terminal to the new controls and states introduced by AI assistance. AI-specific interface elements should expose a clear accessible name, role, and current state. They also need to be reachable by keyboard and provide timely feedback when the tool begins work, requires input, completes an action, or changes focus. Accessible representations of generated output should preserve the actions needed to apply, reject, or inspect that output, rather than requiring users to return to a separate visual view. A notable finding concerns the visual distinction between humanauthored and AI-generated content. Developers must distinguish instructions they wrote from the model’s response. They must also identify tool status and proposed changes. When these elements use nearly identical styling, developers can lose track of an earlier request or struggle to determine what the tool has done. Small text, low contrast, weak hierarchy, and limited zoom support can reduce usability for many developers. However, their effects may be especially consequential for low-vision and color-vision-deficient developers. Theme-aware rendering, sufficient contrast, visible hierarchy, and non-color cues can make these interactions easier to follow. AI panels should also support independent control over text size and typography rather than relying only on application-wide zoom. Our exploratory response pattern analysis further shows that Copilot received more reports from a smaller group of contributors and substantially greater maintainer participation. In contrast, automated closure played a larger role in Claude Code and OpenCode. Automation may help manage large issue backlogs, but it can also make it difficult to tell whether an accessibility report received substantive review before closure. Similar overall closure rates therefore did not necessarily represent similar response processes. The concentration of Copilot reports may reflect sustained accessibility testing or advocacy, although more information about contributor roles would be needed to explain this pattern.

Sabrina Haque and Christoph Csallner

Accessibility barriers can also shape developers’ tool choices rather than merely making a preferred workflow less convenient. One NVDA user wrote: “Personally, I currently like Cursor’s AI intelligence more than that of GitHub Copilot, but I’m forced to use the latter because accessibility reasons.” 17 Other reports described developers abandoning preferred IDE integrations for terminal interfaces because the terminal allowed them to enlarge text to a usable size.1819 These accounts show that accessibility barriers can constrain participation in new AI-assisted development workflows. As AI-assisted development becomes routine, these accessibility issues need to be addressed as core requirements rather than deferred usability refinements.

5 Related Work 5.1 Visual Accessibility Barriers in Developer Tools Blind and visually impaired developers face persistent barriers across everyday programming work. Interviews and observations of blind software developers have documented difficulties with code navigation, editing, and maintaining awareness of program state when using screen readers [3]. A literature review by Mountapmbeme et al. [30] similarly shows that these barriers extend across the development toolchain. Storer et al. [42] found that many of the most difficult problems arise outside the code editor, including documentation, tooling, and information seeking. Even interfaces that appear primarily text-based can remain inaccessible. command-line interfaces, often assumed to be screen-reader friendly, carry their own accessibility problems [39]. Recent work shows that AI-assisted development can both support and complicate these workflows. Flores-Saviaga et al. [18] studied ten visually impaired developers using GitHub Copilot to complete programming tasks. They found that AI assistance could reduce routine effort and support higher-level decision making, but frequent suggestions, context switching, and auditory interruption disrupted participants’ established workflows. Through interviews with 39 blind and low-vision software professionals, Cha et al. [12] found that GenAI supported programming, debugging, documentation, and interpretation of technical visuals. However, inaccessible interfaces and the effort required to verify generated output could limit these benefits. Chen et al. [13] conducted a two-week study with 16 screen-reader programmers using advanced GitHub Copilot features. Their participants encountered difficulties communicating intent, reviewing generated changes, moving between views, and understanding agent status and required actions. Together, this work shows that accessibility in AI-assisted development depends not only on access to individual controls, but also on whether developers can understand, monitor, and act on dynamic AI-generated content. Our study complements these usercentered investigations by examining how visual accessibility barriers are reported in public maintenance channels across multiple AI developer tool ecosystems.

17 https://forum.cursor.com/t/26110 18 https://github.com/anthropics/claude-code/issues/21769 19 https://github.com/openai/codex/issues/3522

Characterizing Visual Accessibility Issues in AI Developer Tools: An Empirical Study

MSR 2026, April 2026, Rio de Janeiro, Brazil

Table 3: Response patterns for visual accessibility reports across GitHub-based issue tracking. Closure percentages use the total number of reports as the denominator, except Completed, which uses the number of closed reports. Human-closed refers to issues closed by a non-bot account. Closure (%) Tool Claude Code VS Code Copilot OpenAI Codex OpenCode

5.2

Bot

Human

Completed

comment (%)

Bot

Human

263 122 71 57

87.5 86.9 33.8 84.2

73.8 10.7 0.0 43.9

13.7 76.2 33.8 40.4

11.3 66.0 66.7 58.3

4.2 66.4 2.8 19.3

29.4 62.2 – 77.7

0.3 4.6 24.8 3.7

Mining Accessibility Related Problems

Limitations

Our study has several limitations. Keyword-based retrieval may miss relevant reports or retain unrelated ones. The 600 reports were selected through unanimous agreement among three LLMs rather than complete manual annotation, although a stratified manual sanity check supported this conservative approach. BERTopic results depend on the selected model and parameters, and the qualitative findings are based on sampled reports rather than the full dataset. The repository metrics describe visible reporting and response activity, but issue closure or a completed status does not necessarily mean that an accessibility barrier was fixed.

7

Median close (days)

Closed

Issue trackers, app reviews, and discussion forums often record accessibility problems as users encounter them, making them a direct source of evidence about accessibility in practice. Bi et al. characterize accessibility issues in popular GitHub projects, showing that such concerns surface widely in issue trackers and cluster around UI design, color, and navigation [11]. A separate challenge is finding these issues among large volumes of unlabeled reports. Aljedaani et al. address this by developing methods to automatically identify accessibility bug reports in open-source systems [7]. A large-scale mobile case study characterize the frequency, categories, and resolution times of accessibility bugs across the Chromium platform [5]. App reviews carry the same signal from the end-user side. Studies have mined and classified end-user accessibility-related reviews in mobile apps [6, 8]. Researchers have also examined developer discussions on Stack Overflow and Twitter, surfacing recurring struggles with screen reader behavior, color contrast, and assistive technology compatibility [4, 23]. Related work has extended this mining perspective to emerging development environments. Mohammadkhani et al. [29] manually labeled 4,762 reviews of low-code platforms and developed a hybrid classifier to identify accessibility-related feedback. Their study shows that heavily graphical development environments can surface accessibility concerns in public user reviews. We extend this line of work by examining reports from issue trackers and forums for AI-assisted developer tools. This allows us to characterize visual accessibility barriers associated with AIspecific interaction surfaces, including chat panels, generated diffs, terminal output, and agent status interfaces.

6

Maintainer

Issues

Conclusions

This study characterized reported visual accessibility issues across five AI developer-tool ecosystems. From a high-confidence set of 600 reports, we found that barriers extend beyond conventional

screen-reader compatibility to include contrast, theme compatibility, visual differentiation, typography and scaling. The distribution of these concerns varied with the interaction surfaces emphasized by each ecosystem. Our exploratory metadata analysis further showed that GitHub-based issue tracking differed in how these reports were handled. Similar closure rates could reflect different combinations of human and automated closure, and maintainer participation varied substantially across repositories. These measures describe visible repository response patterns rather than whether the reported barriers were fixed. By highlighting both the accessibility concerns reported across AI developer tools and the ways these reports are handled, these findings can guide future research and support the design of more accessible AI developer tools.

References [1] Rudaiba Adnin and Maitraye Das. 2024. " I look at it as the king of knowledge": How Blind People Use and Understand Generative AI Tools. In Proceedings of the 26th International ACM SIGACCESS Conference on Computers and Accessibility. 1–14. [2] Toufique Ahmed, Premkumar Devanbu, Christoph Treude, and Michael Pradel. 2025. Can LLMs replace manual annotation of software engineering artifacts?. In 2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR). IEEE, 526–538. [3] Khaled Albusays, Stephanie Ludi, and Matt Huenerfauth. 2017. Interviews and observation of blind software developers at work to understand code navigation challenges. In Proceedings of the 19th International ACM SIGACCESS Conference on Computers and Accessibility. 91–100. [4] Asmaa Mansour Alghamdi, Wajdi Aljedaani, Hamed Jalali, Stephanie Ludi, and Marcelo M Eler. 2025. Understanding developer challenges and trends in web accessibility: a stack overflow analysis. Universal Access in the Information Society 24, 2 (2025), 1701–1717. [5] Wajdi Aljedaani, Mohamed Wiem Mkaouer, Marcelo Medeiros Eler, and Marouane Kessentini. 2024. Empirical investigation of accessibility bug reports in mobile platforms: A chromium case study. In Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems. 1–17. [6] Wajdi Aljedaani, Mohamed Wiem Mkaouer, Stephanie Ludi, and Yasir Javed. 2022. Automatic classification of accessibility user reviews in android apps. In 2022 7th international conference on data science and machine learning applications (CDMA). IEEE, 133–138. [7] Wajdi Aljedaani, Mohamed Wiem Mkaouer, Stephanie Ludi, Ali Ouni, and Ilyes Jenhani. 2022. On the identification of accessibility bug reports in open source systems. In Proceedings of the 19th international web for all conference. 1–11. [8] Eman Abdullah AlOmar, Wajdi Aljedaani, Murtaza Tamjeed, Mohamed Wiem Mkaouer, and Yasmine N El-Glaly. 2021. Finding the needle in a haystack: On the automatic identification of accessibility user reviews. In Proceedings of the 2021 CHI conference on human factors in computing systems. 1–15. [9] Muneera Bano, Rashina Hoda, Didar Zowghi, and Christoph Treude. 2024. Large language models for qualitative research in software engineering: exploring opportunities and challenges. Automated Software Engineering 31, 1 (2024), 8. [10] Shraddha Barke, Michael B James, and Nadia Polikarpova. 2023. Grounded copilot: How programmers interact with code-generating models. Proceedings of the ACM on Programming Languages 7, OOPSLA1 (2023), 85–111. [11] Tingting Bi, Xin Xia, David Lo, and Aldeida Aleti. 2021. A first look at accessibility issues in popular github projects. In 2021 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 390–401.

MSR 2026, April 2026, Rio de Janeiro, Brazil

[12] Yoonha Cha, Victoria Jackson, Lauren Shu, Stacy Branham, and André van der Hoek. 2025. " Game Changer" or" Overenthusiastic Drunk Acquaintance"? Generative AI Use by Blind and Low Vision Software Professionals in the Workplace. arXiv preprint arXiv:2512.24462 (2025). [13] Nan Chen, Luna K. Qiu, Arran Zeyu Wang, Zilong Wang, and Yuqing Yang. 2026. Programmers Who Use Screen Readers in the Vibe Coding Era: Adaptation, Empowerment, and New Accessibility Landscape. In Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems. 1–20. [14] Claude. 2026. Claude Code by Anthropic | AI Coding Agent, Terminal, IDE. https://claude.com/product/claude-code. Accessed June 15, 2026.. [15] Cursor. 2026. Cursor - Community Forum - The official forum to discuss Cursor. https://forum.cursor.com/. Accessed June 15, 2026.. [16] Cursor. 2026. Cursor: AI Coding Agent. https://cursor.com/. Accessed June 15, 2026.. [17] Tanni Dev, Sayma Sultana, and Amiangshu Bosu. 2025. Beyond Binary Moderation: Identifying Fine-Grained Sexist and Misogynistic Behavior on GitHub with Large Language Models. In 2025 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). IEEE, 01–12. [18] Claudia Flores-Saviaga, Benjamin V Hanrahan, Kashif Imteyaz, Steven Clarke, and Saiph Savage*. 2025. The impact of generative AI coding assistants on developers who are visually impaired. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems. 1–17. [19] Gemini API. 2026. Gemini 2.5 Flash. https://ai.google.dev/gemini-api/docs/ models/gemini-2.5-flash. Accessed June 15, 2026.. [20] GitHub. 2026. GitHub Copilot. https://github.com/features/copilot. Accessed June 15, 2026.. [21] GitHub. 2026. GitHub REST API documentation. https://docs.github.com/en/ rest?apiVersion=2026-03-10. Accessed June 15, 2026.. [22] Maarten Grootendorst. 2022. BERTopic: Neural topic modeling with a class-based TF-IDF procedure. arXiv preprint arXiv:2203.05794 (2022). [23] 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. [24] Barbara Leporini, Marina Buzzi, and Giuseppe Della Penna. 2025. A Preliminary Evaluation of Generative AI Tools for Blind Users: Usability and Screen Reader Interaction. In Proceedings of the 18th ACM International Conference on PErvasive Technologies Related to Assistive Environments. 562–568. [25] Jenny T Liang, Chenyang Yang, and Brad A Myers. 2024. A large-scale survey on the usability of ai programming assistants: Successes and challenges. In Proceedings of the 46th IEEE/ACM international conference on software engineering. 1–13. [26] Mary L McHugh. 2012. Interrater reliability: the kappa statistic. Biochemia medica 22, 3 (2012), 276–282. [27] Leland McInnes, John Healy, Steve Astels, et al. 2017. hdbscan: Hierarchical density based clustering. J. Open Source Softw. 2, 11 (2017), 205. [28] Meta. 2026. Llama 3.3. https://developer.meta.com/ai/docs/model-cards-andprompt-formats/llama3_3/. Accessed June 15, 2026.. [29] Mohammadali Mohammadkhani, Sara Zahedi Movahed, Hourieh Khalajzadeh, Mojtaba Shahin, and Khuong Tran Hoang. 2025. Toward Inclusive Low-Code Development: Detecting Accessibility Issues in User Reviews. In Proceedings of the 29th International Conference on Evaluation and Assessment in Software Engineering. 751–756. [30] Aboubakar Mountapmbeme, Obianuju Okafor, and Stephanie Ludi. 2022. Addressing accessibility barriers in programming for people with visual impairments: A literature review. ACM Transactions on Accessible Computing (TACCESS) 15, 1 (2022), 1–26. [31] Alberto Dumont Alves Oliveira, Paulo Sérgio Henrique Dos Santos, Wilson Estécio Marcílio Júnior, Wajdi M Aljedaani, Danilo Medeiros Eler, and Marcelo Medeiros Eler. 2023. Analyzing accessibility reviews associated with visual disabilities or eye conditions. In Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems. 1–14. [32] OpenAI. 2026. Introducing Codex. https://openai.com/codex/. Accessed June 15, 2026.. [33] OpenAI Developers. 2026. GPT-5 mini Model | OpenAI API. https://developers. openai.com/api/docs/models/gpt-5-mini. Accessed June 15, 2026.. [34] OpenCode. 2026. OpenCode | The open source AI coding agent. https://opencode. ai/. Accessed June 15, 2026.. [35] Md Nahidul Islam Opu, Shahidul Islam, Sara Rouhani, and Shaiful Chowdhury. 2025. Understanding the issue types in open source blockchain-based software projects with the transformer-based bertopic. In 2025 IEEE International Conference on Collaborative Advances in Software and COmputiNg (CASCON). IEEE, 01–10. [36] Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer. 2023. The impact of ai on developer productivity: Evidence from github copilot. arXiv preprint arXiv:2302.06590 (2023). [37] PyPI. 2026. langdetect 1.0.9. https://pypi.org/project/langdetect/ Accessed June 2026.

Sabrina Haque and Christoph Csallner

[38] Nils Reimers and Iryna Gurevych. 2019. Sentence-bert: Sentence embeddings using siamese bert-networks. In Proceedings of the 2019 conference on empirical methods in natural language processing and the 9th international joint conference on natural language processing (EMNLP-IJCNLP). 3982–3992. [39] Harini Sampath, Alice Merrick, and Andrew Macvean. 2021. Accessibility of command line interfaces. In Proceedings of the 2021 CHI conference on human factors in computing systems. 1–10. [40] Arghavan Sanei and Jinghui Cheng. 2024. Characterizing usability issue discussions in open source software projects. Proceedings of the ACM on HumanComputer Interaction 8, CSCW1 (2024), 1–26. [41] Stack Overflow. 2025. 2025 Stack Overflow Developer Survey. https://survey. stackoverflow.co/2025. Accessed June 15, 2026.. [42] Kevin M Storer, Harini Sampath, and M Alice Alice Merrick. 2021. ” It’s Just Everything Outside of the IDE that’s the Problem”: Information Seeking by Software Developers with Visual Impairments. In Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems. 1–12. [43] Xinru Tang, Ali Abdolrahmani, Darren Gergle, and Anne Marie Piper. 2025. Everyday uncertainty: How blind people use genai tools for information access. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems. 1–17. [44] TechCrunch. 2025. Cursor’s Anysphere nabs 9.9𝐵𝑣𝑎𝑙𝑢𝑎𝑡𝑖𝑜𝑛, 𝑠𝑜𝑎𝑟𝑠𝑝𝑎𝑠𝑡 500M ARR. https://techcrunch.com/2025/06/05/cursors-anysphere-nabs-9-9bvaluation-soars-past-500m-arr/. Accessed June 15, 2026.. [45] Visual Studio Code. 2026. Build with agents in VS Code. https://code.visualstudio. com/docs/agents/overview. Accessed June 15, 2026.. [46] Yahoo Finance. 2025. GitHub Copilot crosses 20M all-time users. https://finance. yahoo.com/news/github-copilot-crosses-20-million-011655024.html. Accessed June 15, 2026..

Related documents

• How AI Changes DevOps Performance: A Mechanism-Based Simulation#1116745
• To Tab or Not to Tab: Measuring Critical Engagement in AI Code Completion Tools Using Behavioral Signals and Attention Checks#321868
• Breaking, Stale, or Missing? Benchmarking Coding Agents on Project-Level Test Evolution#168382
• Harnessing Human–AI Interpretive Difference: Reflexive, Accountable Computational Interpretivism#977352
• Harnessing Human–AI Interpretive Difference: Reflexive, Accountable Computational Interpretivism#976806