Pith. sign in

REVIEW 4 major objections 3 minor 50 references

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

T0 review · 4 major / 3 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Public issue channels of AI developer tools contain a high-confidence signal about recurring visual accessibility barriers, from screen-reader gaps to contrast and scaling problems.

desk verdict First systematic mining of visual accessibility reports in AI dev tools; taxonomy is plausible, but the cross-ecosystem distribution needs stronger validation. read the letter →

arxiv 2608.05116 v1 pith:4AWXCHPN submitted 2026-08-05 cs.SE cs.HC

Sabrina Haque , Christoph Csallner This is my paper
classification cs.SEcs.HC
keywords visualaccessibilityAIdevelopertoolsscreenreaderissueminingLLMensembletopicmodelingbarrierssoftwareecosystems
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This paper examines 2,652 candidate reports from the public issue trackers and community forums of five widely used AI developer tools—GitHub Copilot in VS Code, Cursor, Claude Code, OpenAI Codex, and OpenCode—and argues that these channels carry a conservative, high-confidence signal about recurring visual accessibility barriers. From a three-model ensemble it retains 600 unanimously positive reports, then uses topic modeling and qualitative coding to identify three recurring categories: screen-reader and assistive-technology barriers; contrast, theme, and visual-differentiation problems; and readability, scaling, and control limitations in AI-specific interfaces. The paper further claims that the mix of these categories tracks each ecosystem's dominant interaction surface, and that the GitHub-based tools differ sharply in how reports are closed and how often maintainers participate. If the claim holds, accessibility work on AI coding tools should target not just screen-reader compatibility but also theme-aware color, visual hierarchy, and independent text scaling, and the public channels themselves are a usable monitoring point.

What carries the argument

The argument is carried by a multi-stage pipeline. Keyword-based retrieval with semantic groups (accessibility, visual impairment, assistive technology, labeling, and visual presentation) cheaply narrows 2,652 candidates; then three large language models from different providers each classify every candidate with a shared prompt, and only reports all three label as visual or screen-reader accessibility are kept, giving 600 unanimous positives. A stratified manual sanity check of 100 reports is used to support the ensemble's conservative selection. The retained reports are then clustered by an embedding-based topic model, which yields three substantive clusters, and 150 stratified-sampled reports are qualitatively coded by barrier type, interaction surface, and subtheme. The load-bearing mechanism is the unanimous-agreement rule plus the manual check that backs it.

What would settle it

Have human annotators label all 2,652 candidates (or a large random sample with confidence intervals) and compare against the ensemble: if unanimous-positive precision falls well below the 47-of-50 rate seen in the sanity check, or if a substantial share of the 413 mixed-label reports are genuine accessibility issues, then the 600-report set and the three-category taxonomy built on it are biased and incomplete.

Watch

Extended reading notes

Core claim

The central discovery is that visual accessibility problems in AI-assisted developer tools extend beyond conventional screen-reader compatibility to include low contrast, hardcoded colors that do not inherit terminal or editor themes, weak visual differentiation between user prompts and AI responses, and font-size or zoom settings that AI panels ignore. The paper documents the distribution of these barriers across ecosystems: editor-integrated Copilot reports are dominated by screen-reader and semantic-access issues (92% of its clustered reports), terminal-oriented Claude Code and OpenCode lead in contrast and presentation problems (55% and 54%), Cursor's AI-panel reports skew toward readability and scaling (40%), and OpenAI Codex, spanning terminal, desktop, and editor, shows a balanced mix. These patterns are derived from a conservative set of 600 unanimously positive reports selected from 2,652 keyword-retrieved candidates, with a stratified manual sanity check of 100 reports supporting the selection, followed by clustering and qualitative review of 150 sampled reports. The paper also shows that similar closure rates across GitHub-based tools can mask different processes, from mostly human closure with high maintainer participation in Copilot to mostly automated closure in Claude Code.

Load-bearing premise

The study hinges on trusting that when three AI models independently label a report as a visual accessibility issue, the label is correct, even though humans rechecked only 100 of the 2,652 candidate reports.

Editorial extensions

If this is right

  • AI coding tools need accessibility work beyond screen readers: theme-aware rendering, non-color cues for diffs, and independent text-size controls.
  • The dominant accessibility barrier follows the interaction surface, so fixes should be targeted to editor chat, terminal agent, or AI-native panel respectively.
  • Public issue trackers and forums, filtered through an LLM ensemble, can serve as a practical monitoring channel for accessibility regressions in developer tools.
  • Similar issue-closure rates do not indicate similar responsiveness; automated closure and maintainer participation must be tracked separately.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same pipeline could be applied to hearing, motor, and cognitive accessibility, or to other emerging software categories such as AI agents in spreadsheets or design tools.
  • The 413 mixed-label reports likely contain additional true positives that the conservative unanimous rule drops; a less conservative threshold would probably raise the category counts and may shift the ecosystem distribution.
  • The concentration of Copilot reports among a small number of reporters hints that sustained accessibility testing by a few advocates shapes the public record, so the issue-tracker signal may underrepresent users who do not file reports.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 3 minor

Summary. The paper studies visual accessibility issues reported in public channels of five AI developer-tool ecosystems (GitHub Copilot in VS Code, Cursor, Claude Code, OpenAI Codex, and OpenCode). It retrieves 2,652 candidate reports by keyword filtering, uses a three-LLM ensemble to select 600 unanimously positive reports, and validates this selection with a stratified manual sanity check of 100 reports. BERTopic clustering on the 600 reports yields three thematic groups: screen-reader and assistive-technology barriers; visual presentation, contrast, and differentiation problems; and readability, scaling, and interface-control limitations. The paper then compares the distribution of these categories across ecosystems, using the three clusters and a qualitative sample of 150 reports, and augments this with an exploratory metadata analysis of issue-response patterns in the four GitHub-based ecosystems. The central claim is that reported visual accessibility barriers in AI developer tools extend beyond conventional screen-reader compatibility to contrast, theme compatibility, visual differentiation, typography, and scaling, and that the relative prominence of these barriers varies with the interaction surfaces emphasized by each ecosystem.

Significance. If the central claim holds, the paper provides a useful and timely complementary perspective to existing user studies of AI coding assistants: it shows what accessibility concerns actually surface in public maintenance channels, and it identifies interaction-surface-specific patterns (editor-integrated, terminal-oriented, AI-native editor, and multi-interface). The study is transparent about its pipeline, uses a conservative unanimous-agreement selection criterion, and includes a manual sanity check. The qualitative excerpts are concrete and make the reported categories credible. The paper also connects its findings to prior accessibility research and discusses actionable design implications. However, the strength of the cross-ecosystem comparative claims is currently limited by the small and coarsely reported manual validation, the lack of uncertainty quantification in the distributional analysis, and the fact that the retrieval and annotation instruments partly predefine the resulting taxonomy. These issues are addressable in revision and do not undermine the existence of the three categories themselves.

major comments (4)
  1. [§2.3] The manual sanity check is too small and too coarsely reported to support the cross-ecosystem comparisons that drive RQ2. The 100-report sample contains only 50 unanimous positives (10 per ecosystem), and the manuscript reports only the pooled result: 47 related, 2 uncertain, 1 unrelated. No per-ecosystem precision estimate, confidence interval, or human-model agreement statistic is given, and the 413 mixed-label reports are never resolved. Because the 600-report set is the input to BERTopic and to Figure 2, any per-ecosystem variation in precision would directly distort the distributions that support the claim that barriers vary with interaction surfaces. Section 6 notes the limited manual check qualitatively but does not quantify its possible effect. Please report per-ecosystem precision with confidence intervals, add a human-model agreement measure, and either resolve the mixed-label reports or explicitly bound their effect on the retained set.
  2. [§3.2 / Figure 2] The distributional comparison rests on small counts and no uncertainty quantification. OpenCode contributes 57 reports and Codex contributes 71 reports to the 567 clustered reports, so the visual-presentation shares of 54% and 55% for Claude Code and OpenCode are computed from small absolute numbers. The 33 outlier reports are excluded from Figure 2 but included in the metadata analyses; if outliers are not uniformly distributed across ecosystems, the displayed percentages can change. No statistical test or confidence interval is provided. At minimum, show per-ecosystem counts and confidence intervals for the proportions, and present a sensitivity analysis for the outlier reports.
  3. [§2.2–§2.3] The taxonomy is partly seeded by the retrieval and annotation instruments. The keyword list and the LLM prompt explicitly name screen readers, contrast, color, font size, and zoom as inclusion criteria, so the three BERTopic clusters are not fully emergent. The qualitative quotes show that the categories are genuine, but the conclusion that barriers 'extend beyond conventional screen-reader compatibility' is partly a consequence of the selection procedure. Please acknowledge this explicitly and, if the claim is to be substantiated, assess whether relevant reports fall outside the predefined categories (for example, by inductively coding a random sample of reports that were not retrieved by the keyword set, or by human annotation without the prompt's category list).
  4. [§2.1] The Cursor data collection is not reproducible. The paper says only that 'threads returned by searches of the Cursor community forum' were collected, without specifying the search queries, result limits, pagination, or how the forum search relates to the universe of Cursor threads. Since Cursor is one of the five ecosystems and drives the readability/scaling pattern in RQ2, the missing search protocol leaves a key part of the main comparison unverifiable. Please provide the queries and retrieval details, or describe the sampling frame explicitly.
minor comments (3)
  1. [§2.3 / Table 1] Clarify the 'Unan.' column and how 'uncertain' labels are folded into 'No'; the current presentation makes the relation between the three-way labels and the binary labels hard to follow.
  2. [§3.2 / Figure 2] Add the per-ecosystem report counts to the figure caption or text, since percentages without counts can be misleading when some ecosystems contribute fewer than 60 clustered reports.
  3. [References] Reference [44] contains a formatting error ('nabs9.9$B'); please fix it. Also consider adding a statement on data and code availability for reproducibility.

Circularity Check

1 steps flagged · score 4.0 of 10

Taxonomy is partly seeded by the keyword list and LLM rubric, but the per-ecosystem distributions and manual validation provide independent empirical content.

  1. self definitional [Section 2.2 (keyword groups) and Section 2.3/Listing 1 (LLM prompt) vs. Section 3.1 and Section 7 (conclusions)]
    "Visual presentation: contrast, color contrast, color blind, colorblind, font size. ... Color contrast, high-contrast mode, dark/light theme readability, or color-only information affecting accessibility; Font size, zoom, layout readability, or visual clarity when it concerns accessibility barriers for low-vision users. ... "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"."

    The candidate filter and LLM rubric explicitly enumerate the coarse categories that the analysis later reports as findings: screen-reader/assistive-technology issues, contrast/color/theme issues, and font-size/zoom/readability issues. The 600-report set is the subset of the 2,652 keyword candidates that satisfies these inclusion criteria, so applying BERTopic to that pre-filtered set and then presenting those three categories as emergent results is partly a restatement of the selection definition. The circularity is partial because the per-ecosystem distribution, qualitative subthemes, interaction-surface mappings, and response-pattern metadata are not predetermined by the rubric.

full rationale

The paper's derivation chain is: keyword retrieval → three-LLM unanimous selection → BERTopic clustering → qualitative taxonomy → cross-tool comparison. The main circularity concern is that the instruments already name screen readers, contrast/color, and font size, so the three-cluster taxonomy is partly imposed by the search and validation definitions rather than fully discovered from the reports. This is a genuine but mild self-definitional issue: it is not a mathematical tautology, and the manual sanity check (47 of 50 unanimous positives judged related, all 25 unanimous negatives judged unrelated) plus the verbatim user quotes give the resulting categories external grounding. There is no load-bearing self-citation: the cited prior mining and user studies are external, and the authors do not invoke their own prior results to justify the classification. The limited manual validation (3.8% of candidates) is a validity and precision threat for the distributional claims, but it is not itself a circularity. Overall, the central qualitative conclusion about 'barriers extending beyond screen-reader compatibility' is partially built into the selection criteria, so a moderate score is warranted, while the distributional and response-pattern findings retain independent empirical content.

Assumptions & free parameters 5 free parameters · 5 assumptions · 0 invented entities

The central claims rest on domain assumptions about the reliability of automated retrieval and classification, plus several hand-chosen analysis parameters. No new physical or formal entities are introduced; the load-bearing choices are analytical thresholds, sampling decisions, and the keyword and prompt definitions that determine which reports enter the taxonomy.

free parameters (5)
  • BERTopic minimum topic size = 15
    Hand-chosen threshold for density-based clustering; it excludes small clusters and directly shapes the three-cluster solution used in the taxonomy.
  • Manual validation sample size = 100 reports (50 unanimous positive, 25 unanimous negative, 25 mixed)
    Hand-chosen stratified sample used to judge LLM agreement; it is small relative to the 2,652 candidates and supports the precision estimate for the 600-report set.
  • Unanimous-agreement threshold = only reports where all three LLMs answered yes were retained
    Conservative selection rule that determines the size and composition of the high-confidence set; other thresholds would change the downstream analysis.
  • Keyword set = five semantic groups (general accessibility, visual impairment, assistive technology, labeling, visual presentation)
    Hand-curated lexical filter adapted from prior work; it sets the recall ceiling for the candidate pool and therefore limits what the study can find.
  • LLM ensemble composition = GPT-5-mini, Gemini 2.5 Flash, Llama 3.3 70B
    Choice of models and providers affects inter-model agreement and any model-specific bias in the unanimous labels.
assumptions (5)
  • domain assumption Unanimous LLM agreement is a valid proxy for human judgment of visual accessibility relevance.
    Section 2.3 builds the 600-report set on unanimous agreement, with only a 100-report manual sanity check and no reported human-model agreement statistics.
  • domain assumption The keyword-based retrieval has sufficient recall to capture the population of visual accessibility reports in these channels.
    Section 2.2 relies on lexical filtering to reduce the full collection to 2,652 candidates; reports that do not match any keyword are never considered by the LLM validation.
  • domain assumption Issue and forum posts truthfully and representatively reflect accessibility barriers encountered in practice.
    Sections 2.1 and 3 treat public reports as evidence of real accessibility problems, but such reports may undercount or overrepresent certain user populations and may be shaped by who chooses to report.
  • domain assumption BERTopic clusters with minimum topic size 15 are stable and meaningful thematic groupings.
    Section 2.4 uses the BERTopic output as the basis for the taxonomy; different parameters, embeddings, or preprocessing could yield different clusters.
  • domain assumption The stratified manual sample is representative of the full candidate pool.
    Section 2.3 generalizes the 100-report sanity check to the whole dataset; the sample is balanced by ecosystem and agreement condition but is small and its representatives is not statistically established.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Characterizing Visual Accessibility Issues in AI Developer Tools: An Empirical Study." pith.science (2026). https://pith.science/paper/4AWXCHPN

@misc{pith2026260805116,
  author       = {Pith},
  title        = {Pith review of: Characterizing Visual Accessibility Issues in AI Developer Tools: An Empirical Study},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4AWXCHPN}},
  note         = {Machine review of arXiv:2608.05116}
}
read the original 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.

Figures

Figures reproduced from arXiv: 2608.05116 by the authors.

Figure 1
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 Open￾Code, 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, com￾ments, comment-a… view at source ↗
Figure 2
Figure 2. Distribution of visual accessibility issue types across [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

50 extracted references · 40 canonical work pages

  1. [1]

    I look at it as the king of knowledge

    Rudaiba Adnin and Maitraye Das. 2024. " I look at it as the king of knowledge": How Blind People Use and Understand Generative AI Tools. InProceedings of the 26th International ACM SIGACCESS Conference on Computers and Accessibility. 1–14

    work page 2024

  2. [2]

    Toufique Ahmed, Premkumar Devanbu, Christoph Treude, and Michael Pradel

  3. [3]

    Khaled Albusays, Stephanie Ludi, and Matt Huenerfauth. 2017. Interviews and observation of blind software developers at work to understand code navigation challenges. InProceedings of the 19th International ACM SIGACCESS Conference on Computers and Accessibility. 91–100

    work page 2017

  4. [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

    work page 2025

  5. [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. InProceedings of the 2024 CHI Conference on Human Factors in Computing Systems. 1–17

    work page 2024

  6. [6]

    Wajdi Aljedaani, Mohamed Wiem Mkaouer, Stephanie Ludi, and Yasir Javed

    work page

  7. [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. InProceedings of the 19th international web for all conference. 1–11

    work page 2022

  8. [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. InProceedings of the 2021 CHI conference on human factors in computing systems. 1–15

    work page 2021

Show all 50 references
  1. [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 Engineering31, 1 (2024), 8

    2024

  2. [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 Languages7, OOPSLA1 (2023), 85–111

    2023

  3. [11]

    Tingting Bi, Xin Xia, David Lo, and Aldeida Aleti. 2021. A first look at accessibility issues in popular github projects. In2021 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 390–401. MSR 2026, April 2026, Rio de Janeiro, Brazil Sabrina Haq...

    2021

  4. [12]

    Game Changer

    Yoonha Cha, Victoria Jackson, Lauren Shu, Stacy Branham, and André van der Hoek. 2025. " Game Changer" or" Overenthusiastic Drunk Acquaintance"? Gen- erative AI Use by Blind and Low Vision Software Professionals in the Workplace. arXiv preprint arXiv:2512.24462(2025)

    2025

  5. [13]

    Qiu, Arran Zeyu Wang, Zilong Wang, and Yuqing Yang

    Nan Chen, Luna K. Qiu, Arran Zeyu Wang, Zilong Wang, and Yuqing Yang

  6. [14]

    Claude. 2026. Claude Code by Anthropic | AI Coding Agent, Terminal, IDE. https://claude.com/product/claude-code. Accessed June 15, 2026

    2026

  7. [15]

    Cursor. 2026. Cursor - Community Forum - The official forum to discuss Cursor. https://forum.cursor.com/. Accessed June 15, 2026

    2026

  8. [16]

    Cursor. 2026. Cursor: AI Coding Agent. https://cursor.com/. Accessed June 15, 2026

    2026

  9. [17]

    Tanni Dev, Sayma Sultana, and Amiangshu Bosu. 2025. Beyond Binary Modera- tion: Identifying Fine-Grained Sexist and Misogynistic Behavior on GitHub with Large Language Models. In2025 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). IEEE, 01–12

    2025

  10. [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. InProceedings of the 2025 CHI Conference on Human Factors in Computing Systems. 1–17

    2025

  11. [19]

    Gemini API. 2026. Gemini 2.5 Flash. https://ai.google.dev/gemini-api/docs/ models/gemini-2.5-flash. Accessed June 15, 2026

    2026

  12. [20]

    GitHub. 2026. GitHub Copilot. https://github.com/features/copilot. Accessed June 15, 2026

    2026

  13. [21]

    GitHub. 2026. GitHub REST API documentation. https://docs.github.com/en/ rest?apiVersion=2026-03-10. Accessed June 15, 2026

    2026

  14. [22]

    Maarten Grootendorst. 2022. BERTopic: Neural topic modeling with a class-based TF-IDF procedure.arXiv preprint arXiv:2203.05794(2022)

    2022 arXiv

  15. [23]

    Syed Fatiul Huq, Abdulaziz Alshayban, Ziyao He, and Sam Malek. 2023. # a11ydev: Understanding contemporary software accessibility practices from twitter conversations. InProceedings of the 2023 CHI Conference on Human Factors in Computing Systems. 1–18

    2023

  16. [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. InProceedings of the 18th ACM International Conference on PErvasive Technologies Related to Assistive Envir...

    2025

  17. [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

    2024

  18. [26]

    Mary L McHugh. 2012. Interrater reliability: the kappa statistic.Biochemia medica22, 3 (2012), 276–282

    2012

  19. [27]

    Leland McInnes, John Healy, Steve Astels, et al . 2017. hdbscan: Hierarchical density based clustering.J. Open Source Softw.2, 11 (2017), 205

    2017

  20. [28]

    Meta. 2026. Llama 3.3. https://developer.meta.com/ai/docs/model-cards-and- prompt-formats/llama3_3/. Accessed June 15, 2026

    2026

  21. [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. InProceedings of the 29th International Conference on Evaluation and Assessm...

    2025

  22. [30]

    Aboubakar Mountapmbeme, Obianuju Okafor, and Stephanie Ludi. 2022. Address- ing accessibility barriers in programming for people with visual impairments: A literature review.ACM Transactions on Accessible Computing (TACCESS)15, 1 (2022), 1–26

    2022

  23. [31]

    Alberto Dumont Alves Oliveira, Paulo Sérgio Henrique Dos Santos, Wil- son 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. InProceedings of ...

    2023

  24. [32]

    OpenAI. 2026. Introducing Codex. https://openai.com/codex/. Accessed June 15, 2026

    2026

  25. [33]

    OpenAI Developers. 2026. GPT-5 mini Model | OpenAI API. https://developers. openai.com/api/docs/models/gpt-5-mini. Accessed June 15, 2026

    2026

  26. [34]

    OpenCode. 2026. OpenCode | The open source AI coding agent. https://opencode. ai/. Accessed June 15, 2026

    2026

  27. [35]

    Md Nahidul Islam Opu, Shahidul Islam, Sara Rouhani, and Shaiful Chowdhury

  28. [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)

    2023 arXiv

  29. [37]

    PyPI. 2026. langdetect 1.0.9. https://pypi.org/project/langdetect/ Accessed June 2026

    2026

  30. [38]

    Nils Reimers and Iryna Gurevych. 2019. Sentence-bert: Sentence embeddings using siamese bert-networks. InProceedings of the 2019 conference on empirical methods in natural language processing and the 9th international joint conference on natural language processing (EMNLP-IJCN...

    2019

  31. [39]

    In2025 IEEE International Con- ference on Collaborative Advances in Software and COmputiNg (CASCON)

    Understanding the issue types in open source blockchain-based software projects with the transformer-based bertopic. In2025 IEEE International Con- ference on Collaborative Advances in Software and COmputiNg (CASCON). IEEE, 01–10

  32. [40]

    Arghavan Sanei and Jinghui Cheng. 2024. Characterizing usability issue dis- cussions in open source software projects.Proceedings of the ACM on Human- Computer Interaction8, CSCW1 (2024), 1–26

    2024

  33. [41]

    Stack Overflow. 2025. 2025 Stack Overflow Developer Survey. https://survey. stackoverflow.co/2025. Accessed June 15, 2026

    2025

  34. [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. InProceedings of the 2021 CHI Conference on Human Factors in Computing Systems. 1–12

    2021

  35. [43]

    Harini Sampath, Alice Merrick, and Andrew Macvean. 2021. Accessibility of command line interfaces. InProceedings of the 2021 CHI conference on human factors in computing systems. 1–10

    2021

  36. [44]

    TechCrunch. 2025. Cursor’s Anysphere nabs9.9𝐵𝑣𝑎𝑙𝑢𝑎𝑡𝑖𝑜𝑛,𝑠𝑜𝑎𝑟𝑠𝑝𝑎𝑠𝑡 500M ARR. https://techcrunch.com/2025/06/05/cursors-anysphere-nabs-9-9b- valuation-soars-past-500m-arr/. Accessed June 15, 2026

    2025

  37. [45]

    Visual Studio Code. 2026. Build with agents in VS Code. https://code.visualstudio. com/docs/agents/overview. Accessed June 15, 2026

    2026

  38. [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

    2025

  39. [47]

    Xinru Tang, Ali Abdolrahmani, Darren Gergle, and Anne Marie Piper. 2025. Everyday uncertainty: How blind people use genai tools for information access. InProceedings of the 2025 CHI Conference on Human Factors in Computing Systems. 1–17

    2025

  40. [2022]

    In 2022 7th international conference on data science and machine learning applications (CDMA)

    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

    2022

  41. [2025]

    In2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR)

    Can LLMs replace manual annotation of software engineering artifacts?. In2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR). IEEE, 526–538

  42. [2026]

    InProceedings of the 2026 CHI Conference on Human Factors in Computing Systems

    Programmers Who Use Screen Readers in the Vibe Coding Era: Adaptation, Empowerment, and New Accessibility Landscape. InProceedings of the 2026 CHI Conference on Human Factors in Computing Systems. 1–20

    2026

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.