"Do You Want Me to Participate or Not?": Investigating the Accessibility of Software Development Meetings for Blind and Low Vision Professionals

Scholars have investigated numerous barriers to accessible software development tools and processes for Blind and Low Vision (BLV) developers. However, the research community has yet to study the accessibility of software development meetings, which are known to play a crucial role in software development practice. We conducted semi-structured interviews with 26 BLV software professionals about software development meeting accessibility. We found four key themes related to in-person and remote software development meetings: (1) participants observed that certain meeting activities and software tools used in meetings were inaccessible, (2) participants performed additional labor in order to make meetings accessible, (3) participants avoided disclosing their disability during meetings due to fear of career repercussions, (4) participants suggested technical, social and organizational solutions for accessible meetings, including developing their own solutions. We suggest recommendations and design implications for future accessible software development meetings including technical and policy-driven solutions.


INTRODUCTION
The Information Technology (IT) sector is a growing part of the global economy.Despite the COVID-19 pandemic, hiring freeze, and layoffs [42], in recent years the IT sector has accounted for more than 10% of the US economy (12.1 million jobs), and has led to over 300,000 additional IT jobs [71]-outpacing GDP growth in other industries [79].Further, positions in the software industry, such as software developers and quality assurance engineers, are projected to increase over 25% in the next decade [16].
However, people with disabilities (PWD) are often left out of the growing IT job market.A general disparity exists between employment and hiring opportunities for people with and without disabilities.In the U.S. in 2022, 21.3% of people with a disability, were employed compared to 65.4% of those without a disability [15].BLV professionals in particular experience lower employment rates than their sighted counterparts [15].An even lower percentage of BLV professionals are employed in the rapidly expanding software industry [77]; only a handful (1.7%) of software professionals surveyed in 2022 were BLV people, although there exists a generally increasing trend of BLV software workers [77].
Prior research has delved into the experiences of BLV developers [25,33,54,59,62,80] and tools for accessible software development [8,24,64].While research shows that the volume of meetings in software development is high [81], and some software developers spend as little as 9% of their workday coding [30], there is little prior research investigating the accessibility of non-programming activities.Meetings play a crucial role in effective software development, as they foster real-time conversations and collaborative problem solving [37], directly influencing successful team outcomes in software development [4,36,76,81,82].However, they have yet to be studied from the lens of accessibility for BLV software professionals.
To address this gap, we conducted a qualitative study to answer the following research questions: • RQ1.What does accessibility look like in various types of software development meetings for BLV software professionals?• RQ2: What strategies do BLV software professionals employ to make their meetings more accessible?
We conducted semi-structured interviews with 26 Blind and Low Vision Software Professionals (BLVSPs) who identified as being blind or having low vision, worked or were working in a position within the software industry, and had at least one year of experience.We conducted reflexive thematic analysis [13], which revealed four main themes: insights about the accessibility of software development meetings and meeting activities; the invisible labor that our participants perform to make their meetings more accessible; the pressure of obtaining accommodations without disclosing disability; and the technical, social, and organizational solutions they propose to support accessible software development meetings.Based on our findings, we discuss the unreliable nature of meeting accessibility, the additional labor generated by inaccessible meetings, and the added burden of deciding whether or not to disclose disability for the sake of potentially improved meeting accessibility.We end with implications for future work on meeting accessibility, organizational policy, and future research on BLV populations.
Through this study, we produce, to the best of our knowledge, the first contributions in the following areas: • The accessibility of non-programming tasks performed by BLVSPs, beyond simply software developers.• The systemic, organizational, and technical challenges that BLVSPs face in software development meetings in the software industry.• The concerted efforts made by BLVSPs to work around the inaccessibility of meetings, including the access labor around disclosure. • Recommendations and design implications for accessible software development meetings.

RELATED WORK 2.1 People with Disabilities (PWD) in the Workforce
Due to inaccessible tools, ableist attitudes, and a lack of accommodations, people with disabilities often have more difficulty securing positions and advancing in their careers compared to non-disabled professionals.For example, a 2015 study found that the employment rate for BLV individuals was 37% [9], compared to 76.2% [23] for their sighted counterparts.Although university degrees are typically associated with better employment outcomes [9], there are fewer opportunities for upward mobility for disabled employees compared to their non-disabled counterparts [34].Potentially because of this, little work exists discussing the experiences of PWD in management or senior leadership positions [67,90].
The Americans with Disabilities Act (ADA) [88], which was passed in 1990 in the US, guarantees PWD protection from unfair discrimination in many aspects of life, including equal employment opportunities and access to "reasonable accommodations" in the workplace [89].For BLV professionals, these accommodations may take the form of screen reader licenses or human readers.Despite these legal protections and guarantees of workplace accommodations, a 2022 study done by the American Foundation for the Blind (AFB) found that of the 323 BLV professionals surveyed, 15% found it difficult to request accommodations from their employers, 17.8% were terminated or passed up for a contract because they were unable to use inaccessible software at work, and 48% faced challenges completing electronic onboarding forms [73].
BLV professionals also experience challenges in their careers due to ableist attitudes in the workplace.At rates of almost 70%, BLV professionals reported encountering problematic attitudes of employers when on the job, with another 43% reporting general attitudes towards blindness as a barrier to their employment [52].BLV professionals even face discrimination in application processes that make it challenging to get hired in the first place [32].There has been work into disability disclosure in the workplace, however such work generally focuses on non-visible disabilities [87].Alternatively, work that does look at the experience of BLV people looks at subjective and psychological measures such as self-esteem and perceived stigma, rather than documenting ableism tied to disability disclosure [61].Some of the concrete effects of ableism are documented in Branham et al. [12], which found that BLV professionals working in ability-diverse environments perform invisible labor-access labor-to create accessible work environments for themselves, and that BLV professionals spend extra time and effort communicating accessibility setbacks to co-workers such that delays are not misunderstood as incompetency or laziness on the part of the disabled workers [12].Due to these and other factors, BLV professionals may often be concerned with losing their jobs due to others' perceptions of their disabilities and may choose to strategically refrain from disclosing their disabilities [72], especially to employers.

Blind and Low Vision Software Professionals
BLVSPs, as a particular subset of all BLV and disabled professionals, have been the topic of several specific accessibility studies.Most of these studies have explored solutions for accessible software development such as tools to create accessible data displays [63], to make programming libraries and IDEs accessible [17,64], and to help BLV programmers navigate and understand code structure [7,8,24].Potluri et al. [62] developed software specifically to make remote collaboration more accessible for BLV developers working in mixed-ability environments, expanding the area of accessibility addressed to more than strictly coding tasks.Other literature on BLV software developers has also looked at non-programming tasks.Pandey et al. [59] found that BLV software developers face a variety of accessibility challenges with everything from programming tasks such as user-interaction design to software tools and quality of documentation related to programming.Prior work has revealed that when visuals are needed (e.g., in brainstorming or organizing project tasks), meetings can be inaccessible [25].Filho et al. [25] and Huff et al. [33] studied issues with collaborative programming, with the latter highlighting that limited knowledge of accessibility among sighted colleagues proved to be an accessibility barrier for accessing job-related materials.Overall, these papers have begun to explore what impact inaccessible tools and systems have on non-coding tasks undertaken by BLV software developers.Storer et al. [80], found that BLV software developers did not consistently feel they could rely on sighted colleagues for assistance as a normal part of team collaboration, instead sometimes perceiving judgement from their co-workers.Similarly, Mealin and Murphy-Hill [54] found that the experience of working in a team was important for the overall accessibility of a given software position.These papers point to the fact that the sociotechnical aspects of software work, beyond conventional programming tasks, can be important for the overall success of BLVSPs.
Prior studies have not fully investigated non-programming tasks such as meetings, positions other than software engineers (e.g., managers and accessibility specialists), or general social dynamics such as how disability disclosure plays a role in software development.Our work delves into these underexplored areas to reveal the specific challenges faced by BLVSPs in software development meetings.

Meetings in Software Development
Meetings are generative activities that constitute and sustain teams and organizations [69].Workplace meetings involve important highlevel activities such as leading, managing time, interacting, and relating which are important for overall organizational success [4].Studies show that while the number of meetings and their duration have been increasing, they remain essential to productivity and other work outcomes [65].
Within software development, meetings are particularly important in fostering collaborative problem solving and enabling communication within teams [37].Having team meetings is associated with higher team productivity; thus, software meetings directly shape team and organizational outcomes [4,36].However, more time in meetings does not correlate to more productivity.In fact, as the number of meetings decreases, the effectiveness of communication increases over the course of development [37].Further, some common team meetings, such as daily stand-up meetings, were perceived as a waste of time or as interruptions to workflow [82].Despite meetings often being perceived poorly, research shows that some types of meetings in software development are considered productive, specifically those in the specification, planning, and release phases of the development process [55].
Lastly, the literature shows that meetings are a large time investment during software development for many members of these teams.On a typical workday, developers reported spending 15% of their day (approximately 82 minutes) on meetings [55].General project members were found to spend 7 hours and 45 minutes in scheduled meetings plus 8 hours 54 minutes in unscheduled meetings on a typical week [81].The same study found that managers spent as much as 14 hours and 21 minutes in scheduled and 12 hours, 42 minutes in unscheduled meetings per week [81].Meetings are a huge element in workers' days, however the perceived or actual usefulness of meetings is variable.

Accessibility of Meetings for People with Disabilities
Since meetings are fundamental components in work and software development, ensuring inclusive meetings is crucial.Various studies have investigated PWD at work revealing a lack of accessibility accommodations [27,39].In the context of remote meetings, workers who are d/Deaf and Hard of Hearing (DHH) experience numerous challenges [21,41,53,84].To help alleviate challenges posed by both in-person and virtual meetings, guidelines have been proposed for inclusive meeting practices, such as saying names before speaking, taking pauses, and minimizing speaking over one another [3].
Prior work specifically reveals issues with meeting accessibility and remote collaboration for BLV users [1,3,20,43,84].Managing multiple aural channels of the screen reader and video call has been shown to be difficult during calls that involve screen sharing [84].Beyond issues with screen sharing, video conferencing tools such as Zoom have been shown to be inaccessible when using screen readers [1,44].When leading remote meetings, BLV facilitators had to perform extensive preparation before meetings, coordinate with human assistants, and maintain awareness of participant activities during meetings [1].In the context of software development, Mealin and Murphy-Hill [54] found that interacting with other developers in meetings was a key accessibility challenge for BLV developers that was best accommodated when sighted colleagues provided relevant meeting material beforehand and made sure to verbalize shared visuals within the meeting [54].Screen readers often fail to interpret diagrams and charts [68], meaning there can still be issues even with accessing directly shared materials.Pandey et al. [59] identified certain types of programming tasks that are relevant for software development meetings (e.g., code review, pair programming, and design activities) and discussed the ways BLV programmers negotiated accessibility with their sighted teammates during these activities.Certain forms of verbalization such as demonstrative pronouns when gesturing to visual content were inaccessible for participating BLV software professionals [25].
While there has been work done on meetings for PWD in general and on accessibility in software development, to the best of our knowledge, our study is the first to focus on challenges beyond conventional programming tasks, such as meetings, for BLV people in a software engineering context.Compared to most general meetings, visual materials in software development meetings are often dynamic, especially in design meetings [50], but equally so in other meetings such as planning and backlog refinement meetings [70].Such meetings not only involve the presentation of visual content, but also constant updates (e.g., modifications to a sketch of software architecture, changes to a Figma prototype of a user interface) -necessitating participating BLVSPs to constantly re-ingest visual materials.Our study acknowledges this challenge and aims to understand its impact on BLVSPs.

Participants
We recruited 26 people who identified as being blind or having low vision, are working or have worked in a software development position (i.e., software engineer, DevOps engineer, tester, accessibility designer, product manager, director, etc.), and have at least one year of experience working in the role in an English-speaking organization.We used this specific participant criteria to acknowledge and include individuals with a wide spectrum of positions who collectively engage in various aspects of the software development process.Participants were recruited through professional contacts, mailing lists such as program-L (online discussion group catered to programmers with visual disabilities), online communities like Facebook groups, and snowball sampling.
To maintain confidentiality of our participants' information, we anonymized identifiable information, including name, age, and job titles.We reclassified job titles into general job categories, since titles can vary between organizations.For example, we categorized participants as Accessibility Specialists if they worked in positions related to accessibility.Accessibility Specialists include a range of positions: designers, testers, developers, and managers.We categorized the type of organization in which our participants have most recently worked in the manner of Pandey et al. [59].
All participants had experience with in person and virtual meetings regarding software development.Participant ages ranged from 20 to 69.Participants self-reported their vision status.Most participants (54%, N=14) self-reported as totally or completely blind.12 (46%) self-reported within a range of visual abilities including legally blind and low vision.Specific participant demographics are explained in Table 1.

Procedure
We conducted semi-structured, audio-recorded interviews with 26 participants over Zoom.Interviews were conducted between late June 2023 and early August 2023, and lasted between 53 and 108 minutes, with an average duration of 76 minutes.Prior to the interview, we emailed participants a study information sheet for review and acquired verbal consent at the beginning of the interview.During the interview, we started off by prompting participants to talk about the types of meetings they have and share their overall experiences with meetings at work, followed by their stories of inaccessible meetings.In the subsequent questions, we asked about disability disclosure in meetings at the workplace, sought their thoughts about career progression in the IT industry, and then wrapped up with asking participants about an ideal future technology in the workplace that could assist participants in meetings.Participants were compensated at a rate of $40 per hour in the form of an Amazon gift card.The study was approved by the Institutional Review Board (IRB).

Data Analysis
All 26 audio-recorded interviews were transcribed and were checked for quality and accuracy by the researchers.We analyzed the data using thematic analysis [13], starting with open coding on each of the transcripts, subsequently developing thematic codes via axial coding to describe commonly emerging themes.The researchers then engaged in memo writing and constant comparison [29] and inductive analysis in the style of the grounded theory method [18].The first, second, and third authors analyzed the same five transcripts through engaging in open coding [18] and discussing initial emerging themes.Thereafter, the first three authors met three times while analyzing the data and iteratively discussed emerging themes across the five transcripts [18].Authors engaged in axial coding [18], analyzing the remaining 21 transcripts in parallel, meeting frequently to discuss findings and reach consensus.The authors were also open to newly emerging themes; when a new possible theme emerged for one of them, all three authors discussed.If the theme was adopted, authors returned to prior interviews and re-coded data for them.For example, when we asked about whether participants disclose disability in their meetings, initial codes such as "being used as a bargaining chip, " "being negatively evaluated, " "being pigeonholed," and "presumed incompetent" emerged from our participants' responses, which led us to the overarching theme of "Risking Judgements and Exploitation."Similarly, participants told us stories of "derailed meetings," "extra meetings," and "low returns;" these initial codes were grouped under the overarching theme "Wasted Time." Both "Risking Judgements and Exploitation" and "Wasted Time" were further grouped under the higher-level theme "Negative consequences of disability disclosure." In this way, our codes and themes map directly onto our paper's headings and subheadings.

FINDINGS
Meetings1 for BLVSPs provide opportunities for "exchanging ideas with other people in real time" (P13), support interpersonal connections, and foster effective communication, which is "huge, especially in the context of being visible to my managers and the rest of the team" (P3).Through semi-structured interviews with 26 BLVSPs, we found that our participants engage in various types of software meetings.While some meetings and meeting activities are accessible, challenges remain within software meetings.Our participants performed additional labor to make meetings accessible and had different perspectives about disclosing their disabilities in meetings.1: Detailed information of participants.For participant anonymity, all participant name were replaced with IDs, age is reported in ranges, and job titles do not include specific position information.The asterisk * signifies positions of management.
Certain software development meeting activities (with sufficient verbalization) were also reported to be accessible.For example, P2, who both goes into office and works remotely, shared that in-person design meetings were more accessible due to meeting participants verbalizing contents.Likewise, P18 talked about brainstorming meetings: "if anyone is sketching something, the designers... know that I'm there so... while they're drawing they're narrating their actions.That's been great." Within debugging meetings, the process of verbalizing the logic around code emerged as an inherently accessible practice for BLV software developers.P2 reported having meeting participants describe their code during debugging sessions "because that's the only way I'm going to be able to know [what is there]" which was not only beneficial for him, but "because they've had to verbalize it to explain what's going on to me... they've found the issue... [like] rubber duck debugging."

Accessibility Challenges in Software Development Meetings.
Accessibility issues were most commonly reported in design meetings, retrospective meetings, pair programming meetings, and meetings with customers or outside vendors.Some of the most prominent issues behind inaccessible meetings were screen sharing, inaccessible software and visual media, and insufficient verbalization from colleagues.
Expressing concerns about the inaccessibility of screen sharing, P1 stated, "The crux of the accessibility issues really comes down to the screen share issue.That's... the most frustrating thing." P7 added that "a lot of blind working professionals don't make use of it very often, but across our enterprise, screen sharing is huge.People love to share their screens.Especially developers; especially designers."Design meetings were challenging when ideas were not "verbalized as much because people are worried about talking over each other" (P2).The accessibility issues inherent in screen share are only compounded when other meeting participants didn't verbalize their contributions.
For our low-vision participants, using screen magnification on shared screens was challenging.According to P11, zooming in on shared content in meetings often broke the software, due to the high scaling.Low-vision participants reported that they had to spend more time navigating around the screen, distracting them from actual meeting contents.When P14 shared her screen, she reduced the text size to be smaller than her normal setting for the convenience of other meeting participants.Even when she was in control and had the choice of sharing her screen with enlarged font sizes, she still compromised her access.
For BLVSPs, screen shared code, including when two people work in pair programming, have significant accessibility issues.Multiple participants shared that while driving pair programming Many software meetings, such as design meetings, architecture meetings, and whiteboarding activities, revolve around visual media and diagrams such as flow charts, infographics, and user interfaces.P3 explained, "diagrams and charts are huge in software development [because] a lot of times to illustrate a concept we'll have some sort of diagram of the system that's being built." This was a major challenge for our participants because screen readers are unable to interpret visual materials, and these meetings are "inherently visual and it's very hard to represent [diagrams and flowcharts] in text" (P3).During architecture and design meetings that involve extensive diagramming, P1 explained that "there's only so much I can do" other than asking "clarification questions, so that I understand and can follow along with what they have up on the board." Some participants mentioned that commercial and internal tools used at their companies were not accessible.P1 and P25 shared: "Retrospectives [are] kind of difficult for me right now.The tools aren't there for retrospectives... at least the ones that are internally used at [company] are just not accessible" (P1).Even widespread enterpriselevel tools proved difficult (i.e., Kanban boards, Jira, Miro, Lucid, Rally, and more), and the inaccessible software tools barred our participants from fully participating in their meetings.Even though Jira, a popular project management program used by software development teams to track tasks and bugs, was accessible for some participants including P19, a majority of our participants described it as inaccessible.Although commenting, editing, and writing tickets with markdown language was reportedly rather easy, many participants shared that navigating through the software, especially in the meeting, was painful (P18, P1).P18 explained that "it does slow you down a lot when you're trying to read through a Jira file at the same time as everyone that's sighted who gets to look at it in the standups."

The Dominance of Sighted Experiences and the Repercussions.
In our participants' workplaces, where a majority of meeting participants are sighted, default assumptions exist based on sighted experiences.For many meeting participants, "it's easy to just assume someone could see what you're doing" (P3).In addition, as P12 humorously recounted, most people assume that there is no BLVSP in software development meetings: "Most people would say, 'Oh, I think there's zero percent chance... that a blind person would look at this. ' Then I could be like, 'Well, okay, so you're wrong.Hi. ' [laughter]" Oftentimes, inaccessible printed handouts are distributed during meetings, with some participants (P24) only finding out midmeeting about the existence of the handouts.P24 then requested a digital, accessible copy, but found there was nothing readily available, leading to post-meeting requests.
Participants dealt with pressure to perceive and interpret information in meetings very quickly.P2 and P26 faced the challenge of keeping up with the fast-paced meetings with their sighted colleagues, who can swiftly navigate through inaccessible information, leaving our participants feeling comparatively slower: "Sometimes you have 15 to 20 people in these meetings, and if you get 18 or 19 sighted people and one blind person, even while the accessibility people may have some awareness, the conversation is moving at such a pace where it's just easy to be left out." (P26) Sighted assumptions and the resulting accessibility challenges prevented our participants from fully participating in meetings and meeting activities.This exclusion resulted in frustrated professionals, who in some cases intentionally ceased participation.P26 explained how inaccessible meetings "felt like a waste of my time."P3 explained the unavailability of slide decks in advance "take[s] me out of the conversation." Silent retrospective meetings led to our participants feeling excluded: "just sitting there listening... no one spoke about what was happening...I totally felt excluded and I didn't need to be here, even though our training says we have to attend all our retros" (P18).In a virtual working era, such exclusion from meetings translated, for P26, into "separations between me and other people on the team... inaccessible meetings helped quicken the burnout...I definitely felt more on the sidelines."Exclusion and inaccessibility caused P24 to completely withdraw from meetings, saying that "usually, I'm able to catch up... if I can't, then I just basically check out and leave." In situations where BLV people set the expectations, meetings are structured differently: "There's a lot of understanding because most of us are all blind, that it might be easier to do certain things outside of the meeting, and then bring them to the meeting" (P26).
When freed from needing to appear sighted, P7 reported that stress reduces.

The Labor of Making Meetings Accessible
4.2.1 Meeting "Pre-Preparation".Like any professional, our BLV participants wanted to appear prepared and knowledgeable in meetings, especially when presenting.However, unlike their sighted counterparts, they had to do additional-sometimes substantialpreparation to overcome accessibility barriers.P3 referred to this access labor as not just preparation, but "pre-preparation", which ranged anywhere from 15 minutes up to two or more hours.
In situations where BLV participants planned to simply attend a meeting, they often needed to request early access to and study materials that would be shared during the meeting, such as agendas and slide decks.P16 described approaching presenters before an in-person meeting to request accommodations, emphasizing that "you really have to push people who you're working with to include you; so I do approach them beforehand, " and additionally requesting a seat next to the presenter and additional time to follow along during the meeting.
P12 explained that about "90% of the time, " PowerPoints contain a lot of visual information, and "in a more technical setting, the automated alt texts are nonsensical." P22 said, "The bigger challenge [than needing to use assistive technology] is navigating the inaccessibility of the content" he receives from colleagues.He described a feeling of being strapped with an "inaccessibility tax" that still leads to an "uneven playing field" during meetings.Perhaps most frustrating for our participants was that, even when they put in the extra effort, inaccessible materials or activities prevented them from staying ahead of the conversation in meetings: "We were doing a design meeting... [although] I'd done two hours of [work] beforehand, I wasn't two hours ahead of everyone else.To be honest, I was only ahead of everyone else for the first like ten minutes.Then, everyone else was just able to navigate the service a lot quicker than me... 'is [this meeting] the most effective place for me to be?'" (P2) Pre-preparation was most intense when our BLV participants were responsible for leading meetings or presenting.Creating slide decks, understanding content in existing decks, and preparing to present decks authoritatively were particularly troublesome.A few participants described needing to present inaccessible slides created by sighted colleagues.Thus, P12 had to "schedule time with a peer of mine to make sure that I know the deck frontwards and backwards.... we go slide-by-slide, to make sure I'm aware of all the information, and then write it in the speaker's notes field, so that I can reference it as I'm giving that presentation." Nearly all participants described creating meticulous presenter notes and scripts and having to"basically commit [everything] to memory beforehand" (P3).Participants described facing the challenge of needing to appear prepared, knowledgeable, and in control to the same degree as their sighted colleagues.As P7 explains, technology often got in the way: "You don't want to be that person in the meeting, especially leading the meeting, who has a blinking cursor [from a screen reader] all over, because it's actively indicating 'Oh, this person's reading, right now.They don't know what they're talking about.'"4.2.2During Meetings.Participants employed various strategies during meetings to get around inaccessible graphics, screen sharing and software, but the workarounds did not always work.
Directly Communicating Access Needs.Many participants chose to directly communicate with meeting participants about their access needs.In project management meetings involving Jira, P7 asked other participants to announce ticket numbers.P18 had "[designers] talk through their design.So they're describing it to me on the fly." P7 reported being in situations where verbal descriptions were particularly important due to platform limitations: "Our QA engineers are using virtualized platforms, and... because there's no screen reader... I'll have to tell them, 'Hey, can you announce the title and the heading and each of the buttons that are on the page?' Basically make them simulate a screen reader, without saying so." Some participants felt uneasy about making verbalization requests or sensed hesitancy in colleagues' voices.P19 recalled, "I was alone with the client...I just asked, without explaining my disability per se, I just told him he needed to speak the values.And even though I felt some frustration in the voice, he did explain them."In software development meetings that were rich in visual content, P18 acknowledged that he "felt like I'm asking for something a little off the grid.Especially in these design meetings where it's like-you know, the blind designer... " Workarounds.Participants implemented various strategies to cope with the inaccessibility of screen sharing.In backlog refinement and sprint planning meetings, P8 shared his practice of working in parallel, keeping Jira open in another window to ensure that he didn't miss critical context and asking clarifying questions as needed.P19 explained keeping two windows open at once meant that he has to be "fast in order not to lose [content].Because if I read about that task when I can listen to what he is saying about the task, maybe he is saying new things which I won't be able to read afterwards compared to the text." Optical Character Recognition (OCR) is another tool commonly utilized by participants as a workaround to gain access to screen shares.P19 resorts to OCR in his meetings when images are shared, but acknowledges its limitations: "in tables especially they don't work.It doesn't read tables as good." P12 discussed using OCR during screen share in troubleshooting meetings: "[It's hard] trying to get the meaning of the code through OCR, which is not optimized to recognize program code.It's [optimized for] English, or languages, ... standard human languages.That can be a little bit frustrating sometimes." Our low-vision participants reported different workarounds to deal with inaccessible screen share during their meetings.On top of using screen magnification software, P11 had his own bucket of techniques including the "shove your face into the monitor" technique, the "squint real hard" method, and requesting the presenter to increase their font size.Additionally, during in-person meetings with shared content, participants dialed into the virtual meeting to access the screen share on their device, ensuring they have equal access to critical materials.When presenting, P24 noted that zooming in on a shared screen has "actually generally gotten positive feedback from people saying that 'I actually liked it because I knew what you were looking at.I knew what you were focusing on.'"Some interviewees expressed concerns that workarounds excluded them from main interactions in meetings.P26 found that the inaccessible tools used in brainstorming meetings (e.g., Miro), impeded engagement.Although the department made efforts to accommodate P26, letting her submit answers separately, this workaround still felt "like there was some separation and exclusion," especially in meetings with a high "sighted-to-blind ratio." She reported that although "people were doing stuff about it... it was slow-going, and it wasn't complete.It still felt like swimming upstream, because you have 18 people doing things one way, and then you have two people who need to do it a different way." Sighted Assistance.Participants occasionally relied on their sighted colleagues for assistance.P7 mentioned that when people worked on visual materials like flowcharts and diagrams, he would "scope it out beforehand" and then discreetly arrange for a team member to join the meeting and help them navigate these visuals.P10 described how back-channel chatting was used to keep them informed during meetings: "I'm getting chats continuously.Boom, boom.Explaining what's going on, because they know, that's one thing that [P10] needs to know about right now, instead of later." In addition, P25 argued it was important to "have other people in the meeting who are good at describing what they're seeing and calling it out.If you have people on your team... who know you, they can smoothly describe what they're seeing." Some BLVSPs chose to decline sighted assistance.P18 explained: "Our company did provide a sighted assistant to help... someone that I could call on to come sit to be with me in the meeting and describe it for me.But I declined.I don't want that kind of help...I felt like the sighted assistance was more infantilizing in a way.It's just highlighting that there's something I can't do.And that means that I have to abide by how they all want to present the meeting, in an inaccessible way.But why do that?Why not just make them present it in an accessible way to begin with?" 4.2.3After Meetings.Our participants often had to spend extra time to make up for inaccessible meeting activities after the fact.P14 acknowledged the challenges of obtaining materials after meetings: "Having to go to somebody else and asking for more information...I feel like I'm putting more burden on somebody else because it's something I can't do myself." After meetings, P18 chose to catch up asynchronously via direct messages with his sighted colleagues, and P9 preferred email over setting up additional meetings when "the blindness got in the way."Many participants even engaged in 'meetings for meetings', scheduling another meeting with sighted colleagues "in addition to the time of the meeting that was already there" (P24) to fill in the blanks.P16 noted that catching up with missed content in follow-up meetings was a multi-step process: "The meeting was about two hours at that time.And catching up with the meeting... did not happen in just one go...I had to let go of some part of it also because I can't ask them to [explain everything].I can only justify asking them what is relevant to me."For participants who are in managerial positions, 'meetings for meetings' sometimes failed as they had too many other scheduled meetings.P22, P12, and P23 reported having to "just move on" (P22) in some cases, because they "don't always have the time" or are always "off to other meetings" (P23).

4.2.4
Developing Accessible Meeting Practices.Our participants collaboratively developed accessible meeting practices with their sighted colleagues, both intentionally and spontaneously.
Meeting accessibility was often achieved through open communication.P12 shared, "the most common solution to accessibility is communication... just making sure that people are aware, or telling people that they have to be very specific." For P18, the team now naturally makes meetings accessible: "for the most part, and as people know me and they know the other disabled folks that are there they'll start... baking it in.They don't even have to think about it anymore, they just do it naturally from the start, being accessible and inclusive.Which is all we can ask for." However, maintaining inclusive meeting practices can be difficult over time for some team members.P1 explained, "I do try to explain to my teammates what I need, but it's difficult to change your ways and multitask, if you aren't used to maintaining that constant flow of dialogue and communication, while writing code at the same time." Some participants' teams decided together what software to use to ensure its accessibility for everyone, as P26 shared, "I think just being on this different team... where we can decide among ourselves, 'OK, this is a good platform to use, this is how we're gonna do things.'"However, some participants worked on teams that were less cooperative regarding accessibility: "Sometimes it's not even about the technology.It's about the people you work with...If other people-your teammates, your colleagues-don't understand things from your perspective, or have at least some kind of empathy, it's not going to work out." (P5)

Disability Disclosure in Software Development Meetings
Participants described expending a great deal of energy constantly weighing the tradeoffs of disability disclosure to colleagues, supervisors, external vendors, and clients.P4 noted that "it's a tradeoff, and [disclosure] can be stressful" because there can be personal and professional consequences to disclosing one's disability in the workplace.Yet, without disclosure, one risks not being able to access information needed to fully participate: "I do have to weigh disclosing and getting more information versus what information I think I'm missing based on the meeting... [having to weigh disclosure in a meeting is] not exactly a fun position to be in, but it is a position that I have to be in.So, I come up with my strategies and deal with it." (P12) Like P12, all participants had strategies for navigating the choice of whether and when to disclose.While some chose to embrace disclosure, others reported performing extensive additional labor to avoid it.Unfortunately, in many cases, participants reluctantly disclosed because they felt they lacked better alternatives.

Embracing
Disclosure.Some of our BLVSPs had no concerns disclosing their disabilities in meetings and did so as a matter of advocacy.Generally, those who work as or work with accessibility specialists expressed more comfort with disclosing disability.As P26, an accessibility specialist, shared: "I don't see myself needing to avoid it.Especially being in an accessibility department."Similarly, P18, also an accessibility expert, shared that "I just speak up for myself pretty quickly.I ... come off mute and be like 'Hey, blind guy here.If we're talking through this, let's talk through everything.'"From his perspective, disclosure in meetings simply "makes life a lot easier." Disclosure of visual ability was also a means of managing others' perceptions of how "actively engaged" one is in the meeting: "I'd far prefer to say, 'I'm blind.I can't see the screen... if you could send me the PowerPoint deck afterwards, I'll review it, and pick up on the things I didn't [get].' I would never want to not disclose ... if lack of disclosure made me seem like I was not actively engaged." (P13) Disclosing disability was seen as an act of conveying expertise, with several accessibility specialist participants emphasizing that their disability identity gives their words more weight and credibility in meetings.P23, for instance, feels he can offer "credible" accounts: "I've experienced what it is like to use software that's not accessible.So when I disclose my disability and describe some of my experiences, it has more impact than just being quiet." Access Façade.Some participants reported that they would sometimes pretend to have full access.P3 noted that one of his tactics is "BS-ing [his] way through things" by piecing together information he already knows to fill in the blanks.P12 explained that, even if he has pre-prepared for a presentation, meeting expectations are dynamic and may require one to "fake knowledge" and "do a little bit on-the-fly work." Another tactic to "sideswipe the disability conversation, " demonstrated by P7, was to insinuate he was looking at a different window, when he could not see the shared screen contents: "I will make a point of saying, 'hey, when you reference a story or an issue, would you be able to announce that key, just so I can pull it up on my side, and pull up my personal notes.' That's another thing I find works very well.... even if you don't have to make personal notes, indicate that you do have them... because they're going to naturally assume you're in a different window, you're looking at your notes, you're providing that additional insight that you can only get by looking at another window.Therefore, you can't see their spreadsheet.Or you can't see what they have up.... that's another way you can sideswipe the disability conversation, if it's not productive to have... " P7 cleverly indicates that he is perhaps even more engaged than others, subtly and indirectly communicating his commitment and expertise while avoiding the disability conversation.
Leveraging Conversational Nudges.Participants developed creative strategies to steer other meeting attendees away from inaccessible conversations.In other words, participants would 'nudge' [85] their sighted participants towards taking certain actions.We refer to this as a 'conversational nudge'.P7 sometimes asked colleagues, "Hey, can you describe that in more detail?",as did P3: "I'll guess at what they're saying.But I'll say it in such a way that prompts them to clarify what they're saying... Which can be weird if the answer is obvious on the screen.... So I just have to be creative about it." P12 similarly flips questions directed at him back towards the customers whose slides have inaccessible visuals, letting him off the hook for disclosing disability and pivoting the meeting into a more productive conversation: "I was in a meeting... and [the customers] were asking me... 'at this point here [in the process diagram on the slide], is this where you step in?'And so, I would say, 'I think that we're capable of stepping in wherever you need us.Where do you think we should step in?' ...And then, that gets them talking about, 'Well, we need help with the actual data cleaning, or blah, blah, blah.' And, just like that, manage to kind of redirect that question into something potentially even more positive, right?" 4.3.3Reluctantly Disclosing.Most of our participants indicated a desire to avoid disclosure unless strictly necessary or unless the technology "outed" them, leaving no other choice but to disclose.For example, P13 said "If I'm in a meeting, and they're saying 'If you look at this slide-', it's like, 'No... can you describe it?'That tends to be the main reason for disclosing."P7 mentioned that he will "deliberately do everything that I can, to understand what is on the screen" before he brings up his disability.Participants tended to express a feeling of, for example, having "no alternative" (P4) or "hav[ing] to" (P14) disclose to gain access.
Participants had the least control over disability disclosure in situations when their screen reader played a role in meetings.P13 discussed meetings with vendors where he would be "doing something where they're going to hear my screen reader" at which point:"I tend to disclose my disability when it's obvious that not disclosing it would be an omission." Moreover, P7 shared: "[The visible cursor is] just another factor that's going to indicate to the audience that you have that disability... [Who knows] whether or not that impacts or lessens their opinion of the content that you're trying to convey."

Negative Consequences of Disclosing Disability.
Wasted Time.Participants reported wasting time in derailed and extra meetings.One of the most commonly reported consequences of disclosure in meetings is that it "will somewhat derail the meeting" (P12), with P7 echoing that engineers were likely to then fixate on his disability.P13 described different means of curtailing inappropriate tangents: "I will try to use humor, or something else to shut it down, say, 'Hey, I'd be happy to talk to you about this, but this is probably not the place.'"P12 expressed feeling misplaced guilt in situations like this: "Then I feel responsibility for derailing the meeting.... It's not my fault, [but] it's still something about me, and I feel bad." Time costs can be significant when disclosing.Sighted attendees might "spend half an hour of your 45 minute meeting going, 'Wait, blind people!?'" (P12).
BLVSPs are sometimes saddled with the access labor of followup meetings to educate their colleagues about their disability, as P12 detailed: "[This meeting] got so derailed that we had to do a followup meeting... but separate to that, I scheduled a one-on-one meeting with her just to talk about what it's like to have a disability, and how I can do what you can do, but I just might do it differently." P12 explained that he used to have time when he was a developer to do the labor of "holding people's hand through their own personal issues or preconceptions [about disability]," but now that he is a manager, increasingly "important people's time" (like an executive's) is taken up by derailed meetings.
Risking Judgements and Exploitation.After disclosing disability in the workplace, participants risk becoming "that blind guy" (P7) and their disability being a "primary trait" (P13).P4 explained that, because he is blind, he often gets pigeonholed into accessibility roles and conversations, even though he shared that "if I wasn't blind, I would not probably be into accessibility...I want to be involved in other conversations and other projects [about machine learning] that aren't related to those issues." Participants explained that there's "stigma around disability still" (P3).Participants like P5 felt "judged" and feared "they will [assume], 'Yeah, she always has problems.'"According to P26, the stakes can be particularly high when giving a "polished presentation" and technical issues arise, "Cause then people do think that 'Oh... obviously, she's having trouble 'cause she's blind.'"Some participants, such as P10, even reported being entirely excluded from meetings due to misconceptions about their capabilities.P23 was excluded from UI diagramming as "nobody will even describe them to me," making him unable to give valuable input.Beyond individual acts of exclusion, P5 feared "long-term consequences" in the form of negative performance reviews from supervisors.P5 described feeling a lack of trust when disclosing episodes of migraines and the resulting onset of low-vision to her manager and some colleagues; "people were understanding [in the moment], but that definitely reflects on your performance later." One of the most concerning consequences of disclosure comes from interactions with outside vendors, clients, and potential customers.Meetings with these parties tended to be inaccessible, perhaps due to reduced ability to request meetings in advance or to educate these parties about how to run accessible meetings.For example, P4 expressed concern of working with clients who were primarily software developers: "They didn't really know anything about accessibility... it was kind of stressful working with them... if I had explained what my vision was... they probably wouldn't have wanted to work with me." Concerns in external meetings were amplified when disclosure could lead to lost business.As P12 reported, "I'm terrified of a customer's disbelief that a blind person could do something would influence their decision to use our software, " especially since he is working with "three, four million dollar contracts." P19 reported that, in the cut-throat international competition for outsourced labor, his disability could even be used as a bargaining chip to pay less for software services: "Many people don't understand what I can and can't do.They also find this as a negotiation point.Because even though they know what a blind person can do, they can try to use this to lower the price in the negotiations with my boss... "

Potential Solutions for More Accessible
Software Development Meetings 4.4.1 Self-Made Solutions.Given their expertise in software development, some of our BLVSPs developed their own technical solutions to work around meeting inaccessibility.P2 and P4 described developing tools to help them use OCR to access screen shares: "I've created a tool where...I can draw a box on the screen and then it will take a screenshot of that area and it will send that screenshot to an optical character recognition tool and then it will send whatever the output is to a speech synthesizer and read it out loud to me." (P4) Participants also developed tools to hear their screen readers over other voices in the meeting and keep their faces centered in the camera view.P19 described sitting in long meetings where his co-workers could multitask.This multitasking was inaccessible to P19, since he couldn't hear his screen reader over the meeting volume, and decreasing the volume manually was cumbersome.Long before being included as a default function of a screen reader, P19 developed a screen reader plugin called 'volume docking' to reduce the volume of other sounds such as meeting participant voices when the screen reader is actively speaking.Additionally, P2 developed a program that supports his in-camera positioning: "I wrote a tool that uses offline face recognition to give me verbal guidance of where my face is... the problem is that, depending on who you're having the meeting with, they won't feel confident in telling you that you're not in shot... because of this tool, it's one less thing that I have to worry about." Unique to BLVSPs is their expertise with technology that can support their development of tools for workarounds.As a software engineer, P2 described himself as a tool smith and supports other blind people in doing so: "I'm a very strong proponent of blind people having to write their own tools.... Ideally, you wouldn't have to.But it's good to become a tool smith." 4.4.2Future Technologies.Participants ideated on technologies to support accessible meetings.
Image Interpretation.Participants proposed multiple future tools that could be used to interpret and describe visual materials such as screen shares and diagrams used inside and outside of meetings.Since "screen share is really just images" (P25), participants envisioned Artificial Intelligence (AI)-driven technologies that could describe the images displayed or diagrams being worked on.For example, P6 imagined a voice assistant that was capable of "reading off what's on the screen maybe.Especially if someone is screen sharing."P8 also described how Large Language Models (LLMs) could be utilized via text commands to increase diagram accessibility:"[LLMs] might help with recognizing images and describing the interesting part of an image.A problem for me is noise...So something that would help me filter in such an environment." Note-taking and Summarization.Some participants ideated around using AI to support note-taking during "very fast-paced" meetings (P7), creating "quick summaries of context potentially missed during the meeting [or an] actual intelligent assistant [so] I could tell it to clean up my notes" (P3).However, P3 expressed concerns with data privacy and the potential for over-reliance on services: "I work on a proprietary and confidential code base.IP in technology is really important... Privacy is a big concern.The over-reliance on the tool is also a big concern to me... What if I over-rely on AWS, Amazon, Chat GPT, or whatever and then they yank that service from me?" Accessible Screen Share.Multiple participants ideated on improving the accessibility of screen share.For example, P21 shared that redeveloping "the share screen function to be more accessible is a pipe dream because the way it's implemented is not conducive to accessibility because it's literally just sharing the video feed."One way to transmit more accessible information while screen sharing is by sharing materials directly.P16 would like to "access the same thing a person who is sharing...at the same time.If it's a window or an app, anything... allow me to go through exactly the same thing at the same time."Rather than get access to materials locally through screen sharing, P25 and P11 envisioned being able to use a screen reader to "pierce through a screen share" (P11), like if the materials were local, and P11 suggested local screen magnification awareness: "If the conferencing software knew that you were trying to zoom in on part of the thing being shown, then if that information could make it all the way from your screen magnification of choice, all the way to the other person's computer, then that means that the sending computer would be able to request, 'Hey, this is being zoomed in on.Please send more detail.'"4.4.3Meeting Practices.Participants proposed a variety of recommendations for interpersonal improvements to meeting accessibility.Proposals included individual advocacy such as "being able to advocate for yourself, having people in your corner" (P9) and "engineer[ing] [your] way around accessibility problems" (P2), collaborative efforts, and setting corporate standards, guidelines, and training.At the heart of many of the suggestions is creating a culture in which BLVSPs shoulder less of the load, and in which team members are allies: "It would be nice to not always have to pull all that weight.... If no one else is bothering to say anything... it's like, 'Well, do you want me to participate or not?... If you don't value my contribution, why am I here?'"(P26) Managers can "unilaterally decide that we're going to handle things by 'Everybody please stay muted until you have something to say'" (P23).However, participants recognize that implementing accessible practices requires organizational change and setting standards: "The office team reached out directly to me, which it did to every new hire: 'This is the email you use if you have any accommodation requests or if you have any feedback for the office team...'" (P18) In contrast, P5 explained that at her company: "you especially have to do everything online.Not through a person first.And there was no option to even list exactly what I was experiencing....there was no option for me to fill out that I need [meeting] flexibility." P5 was unable to fill out her company's accommodation form, since her condition did not fit into one of the predefined disability categories.
Additionally, technology procurement and meeting room equipment by default were inaccessible: "All of our meeting rooms that are set up for virtual meetings have a touch screen that you have to interact with.And it's a locked-down system that you can only interact with the touch screen.There's no keyboard, there's no chance to load on JAWS.There's nothing." Appropriate corporate policies can ameliorate such challenges, but they need to be combined with training at all levels, from software developers to Human Resources (HR), organizational practices, employee well-being, and procurement.

DISCUSSION
Though much attention has been paid to the accessibility experiences of BLV programmers, this is the first research study to explore the accessibility of software development meetings from the perspectives of a range of BLVSPs.Here, we discuss how our findings corroborate some of those from existing literature on (1) accessible software development and (2) accessible remote meetings, and offer new insights on accessibility challenges being faced, workarounds being employed, and open questions remaining.
In this study, we aimed to learn more about software development meeting accessibility, and themes emerged regarding technical and social challenges within software development.Supporting prior research, our participants faced hurdles co-piloting when pair programming [25,33,59], had difficulties creating and interpreting UML diagrams [2,47,54,59], struggled to understand and navigate project management task boards via software like Jira [25,59], and commonly sought sighted assistance [2,54,59].Our participants indicated that colleagues with disability knowledge and empathy helped collaboratively co-create accessibility in the workplace [80], though they felt sighted colleagues sometimes lack the knowledge to be useful guides, leaving BLVSPs with the invisible work of educating them [59].BLVSPs encounter these technical challenges, often daily, in all sorts of settings.In the context of meetings, however, we found that when simultaneously trying to converse and deal with inaccessible tasks, the accessibility problem escalates and increases access labor, contributing to further meeting exclusion.
In addition, themes emerged regarding accessibility of meetings in general, which replicate some findings primarily reported in recent studies by Tang [84] and Akter et al. [1].Five of seven BLV participants of Tang's study [84] and two of 18 facilitator participants in Akter et al.'s study [1] were BLVSPs, and similar to our study, they reported requesting meeting materials in advance, inaccessibility of initiating and observing screen sharing, asking for sighted assistance during meetings can be "socially problematic", and handling cognitively demanding situations such as attending to audience engagement.Adding to prior findings about meeting accessibility, we contributed the unique challenges BLVSPs face in software development meetings, including the access labor of disability disclosure in meetings.
Below, we further unpack those findings that are particularly new in the context of existing literature, either by providing a new perspective altogether or by situating existing findings in the context of software development meetings, which have their own peculiarities and thus introducing challenges for BLVSPs.We organize these findings along three themes: (1) the varying accessibility of software development meetings, (2) the access labor generated by meetings, and (3) the access labor generated by disability disclosure in meetings.We then discuss the implications of our findings for researchers.

The Varying Accessibility of Software Development Meetings
Despite the criticality of meetings, we found that they are not reliably accessible.Meetings posed new and complex accessibility challenges for BLVSPs due to the high levels of interpersonal communication and collaboration that distinguish meetings from independent work.Our analysis revealed that accessibility varied across meeting type (e.g., daily stand-up versus design meeting) and within meeting types (e.g., design meeting relying on visual versus textual documents), answering RQ1.These variations were out of our participants' control, impacting their ability to participate and contribute on equal footing as sighted colleagues.
Another variable affecting meeting accessibility is who is in attendance.Particularly in meetings, as opposed to independent work, there is a high likelihood of encountering unfamiliar people.With this came uncertainty about who would be in the meeting, to what extent the meeting practices would be accessible, how much disability awareness participants would have, and whether it was safe to disclose one's disability.Especially when external vendors, clients, or prospective clients were in the meeting, participants perceived there to be a greater chance of inaccessible materials and disability discrimination.We found that sighted assumptions prevailed in meetings, given the majority of participants usually were sighted.This resulted in fast-paced meetings where our BLVSPs were pressured to keep up with sighted colleagues, resulting in hindered participation and feelings of exclusion and frustration, sometimes even ceased participation.Particularly in the context of the particularities of software development meetings, where materials not only are presented but also undergo many real-time updates by the team, we found that this introduces additional challenges for BLVSPs.For example, because design meetings require constant re-ingestion of highly dynamic visual documents, BLVSPs like P2 invested hours in preparation, only to be outpaced by sighted colleagues in a matter of minutes.

The Additional Access Labor of Meetings
Regardless of the varying degrees of meeting accessibility, all of our participants engaged in additional labor both within and outside of meetings to gain access (answering RQ2, see Figure 1).It is well-known that BLV people need to perform such additional labor in different kinds of settings [10,12,20,40,59]; our contribution is documenting what kind of labor is needed in the context of software development meetings.Participants reported having to gather materials before and after meetings to gain access, consistent with what is already suggested in "meetings science" [57,83] as best practices for everyone.The absence of adherence to these guidelines, however, generates excessive access labor, leaving all of the burden on BLVSPs' shoulders.

Figure 1: Access Labor in Meetings
Other access work we document goes beyond best practices and considerations.Before meetings, participants would memorize presentation materials and develop and disseminate their own accessibility training materials to colleagues.During meetings, participants developed multiple workarounds such as seeking sighted assistance [1], but also declined assistance on some occasions.They also used multiple virtual desktops [84] and utilized OCR on shared screens [22,84], though neither of these were reliable or usable solutions for our BLVSPs.Even after the meeting, participants had to collect materials shared during the meeting and set up and additionally engage in "meetings-for-meetings" to catch up on what was missed.
Unseen in prior work, we found that our participants spent time outside of work devising tools to enhance meeting accessibility, leveraging their domain expertise.While this is extra labor, it demonstrates that not only are BLVSPs adept users of software, but also active creators of software tools contributing to enhanced meeting accessibility.

The Labor of Disability Disclosure in Meetings
Our work reveals that weighing whether or not to disclose disability in meetings-and dealing with that decision-constituted an additional form of access labor that is overlooked in literature (answers RQ1 and RQ2).There has been little work within ACM venues on disability disclosure, with two notable exceptions [26,49].Both of these works focus on chronic illness, as opposed to visual impairment.
In the United States, the ADA guarantees workplace accommodations for people with disclosed disabilities and establishes the right of people with disabilities not to disclose [88].However, the promise of access was not reliable enough for many of our participants to disclose, and the social and technical aspects of meetings sometimes stripped them of their agency by "outing" them.Further, the work of navigating disclosure was never finished; each new meeting could be another decision point around disclosure.Regardless of participants' disclosure decisions, they performed a substantial amount of additional access labor.When participants chose to disclose disability, their labor primarily revolved around educating meeting participants about blindness, even occasionally scheduling additional meetings to discuss disability in detail.Even though disclosure could lead to benefits such as conveyed expertise and improved access, numerous drawbacks accompanied this choice, including: wasted time, being pigeonholed, being presumed incompetent, being excluded from meetings, and the career risk of being negatively evaluated.Additionally, BLVSPs had to have conversations to educate others about disability when they disclosed disability.When dealing with others' disbelief that a BLV person could be in software development, they felt objectified as "inspiration porn," a term Stella Young coined [92].Indeed, many of our BLVSPs were regularly left feeling like an outsider in their own workplace.
When participants chose not to disclose disability, they had to perform extensive workarounds and implement avoidance strategies such as "conversational nudges" to participate without surfacing their disability.Our BLVSPs were highly independent and techsavvy IT knowledge workers; yet they grappled with inaccessible technology on a daily basis, sometimes even being "outed" by their own assistive technology as it interacted with collaboration software in meetings.Being outed not only diminished participants' autonomy, but, it also carried with it the same burdens as voluntary disclosure: explaining their disability, being pigeonholed and excluded from meetings, and the many other documented potential risks of disability disclosure [6,19,28,66,91].Depending on their position within the organization and the nature of the meeting, we found different BLVSPs bore a greater or lesser burden.Although participants mostly chose to disclose disability only when necessary, everyone had different thresholds of necessity.For example, while developer participants were generally reluctant to disclose their disabilities in meetings, accessibility specialist participants were generally more open to disclosing, perceiving it as giving them more credibility in their role.Further, meeting accessibility improved as BLVSPs advanced in their careers.Upper-level management meetings were more accessible than the technical, "in-the-weeds" (P22) development meetings, and participants were more comfortable disclosing disability in meetings if they occupied positions of leadership and seniority, which afford them more powerful, "big voices" (P9).

Implications for Research
5.4.1 Technical and Policy-Driven Solutions for Accessible Meetings.We found that meetings can be fast-paced, contain content that is currently fully or partially inaccessible, and require disruptive and cognitively demanding tools and workarounds.With the advent of AI and highly advanced tools, an opportunity exists to enhance the accessibility of software development meetings by taking advantage of existing tools (as recommended by P7) that rely on audio and textual summarization [45,75], smart guidance across the screen, sonification of screen information [63] or even interpretation of diagrams (e.g., P25, P8) and revisions [60], and more.Such technologies could truly change how BLVSPs engage in meetings, and perhaps make it easier for those who could not attend a meeting to get a summary or understand how arguments, designs, or decisions were made.Additionally, future work could explore solutions to reduce the labor of educating colleagues (e.g., P12) about accessibility and disability.For example, non-disabled team members could interact with a chatbot [51] to learn about various disabilities and the assistive technologies used by colleagues and people buying their products.This chatbot could prioritize referring users to content online created by people with disabilities, such as program-L [35,58].
Today's LLMs and AI, however, are not yet at the level that they can fully assist in meeting accessibility since they don't necessarily work well at summarizing content and have a difficult time processing large amounts of audio [45].There also need to be changes made at the corporate or organizational level including the "policy, practices, and culture" that impact accessibility in the workplace [67].Future work should investigate automatic systems for meeting invites [38] that would inform participants about company accessibility policies and prompt accessible meeting practices based on these in situ [74].Such systems might suggest accessible tools or collect accessible meeting materials and notes in advance.
Regardless of what form these organizational changes take, future work needs to include the perspectives of people with disabilities when making and enforcing improved accessibility standards.

Towards Low Vision
Research.The term 'BLV' includes a wide range of visual abilities and acuities [86]: from being totally blind, being low-vision with a certain amount of eyesight left, to even being intermittently low-vision (e.g., P5).We found that the experience of low-vision professionals in meetings who use screen magnification and totally blind people who use screen readers differ significantly.Existing research, including our own, commonly merges 'blind' and 'low-vision' into 'BLV' and is skewed towards total blindness.Yet, globally only 4% of people with visual disabilities are totally blind [11], leaving the low-vision population relatively understudied.Thoo et al. [86] found that out of 100 manually coded BLV research papers, only 6 specifically looked at low-vision users.Our study incorporated a comparatively high number of low-vision professionals, which allowed us to uncover key insights about unique situations, for instance where some participants (e.g., P5), were further marginalized because their disabilities were not acknowledged or accommodated by coworkers or their organizations.In contrast, totally blind and some low-vision people are generally believed-although not necessarily understood-without further explanation when they disclose their disability.We suggest future accessibility researchers further investigate the experiences of professionals with different types of visual disabilities in different contexts of meetings and work.

LIMITATIONS
All of our participants resided in the United States of America, Europe, or India, thus our findings may not apply to other cultures or geographic areas.While our total number of participants ( 26) is double the median ( 13) in accessibility research focusing on BLV individuals [48], our study has limitations in sampling diversity.Our participants' gender demographics are skewed towards men (22 men, 4 women), which is a known challenge in studies in the software development context.Also, our study did not investigate how intersecting identities could affect our participants' work experience.
We included low-vision professionals in our study, which significantly enriched our findings and research procedures.However, with 14 out of 26 participants (54%) self-identifying as being completely or totally blind, the percentage of low-vision software professionals is not representative of real-life demographics, where 85% of the U.S. BLV population is low vision [5].More comprehensive research is warranted, particularly focusing on sub-populations of BLV that are most common, including those with low-vision or intermittent vision disabilities.
Prior work has identified benefits for remote work for people with disabilities, but very few advantages were reported by BLV individuals [14,21,31,46,56,84].In our work, BLVSPs did not specifically emphasize the challenges of remote over in-person meetings.This may be because most participants' meetings were remote, and our participants rarely distinguished between in-person and remote meetings.
We did not cover every role within the software development process (e.g.requirement engineers).Nonetheless, our study sampled a much wider range of job positions in software development compared to prior research, and we ensured that years of experience, seniority, and specific positions varied.

CONCLUSION AND FUTURE WORK
We investigated the accessibility of software development meetings for BLVSPs.We conducted semi-structured interviews with 26 BLVSPs and identified four novel themes: (1) certain meetings and activities were prone to accessibility challenges, (2) participants performed significant additional labor to get access, (3) participants avoided disclosure in meetings but were sometimes forced to disclose, and (4) suggested solutions for more accessible meetings.We validate findings from previous literature that also hold true in software development meetings, but to this we add several unique findings.Most notable among them include the multiple nuanced layers behind the access labor of disability, conversational nudges, engaging in meetings for meetings, and crafting personalized solutions towards improved meeting accessibility.These findings point to important next steps to enhance software development meeting accessibility, including more investigations including the low-vision population and technical and policy-driven solutions.
Future work could involve further exploration of the nuances of the accessibility tradeoffs of in-person and remote software development meetings.Also, further investigation is needed to validate the recommendations from our study.Future work should realize the technical solutions proposed by our participants including better OCR, and AI-based tools to interpret and narrate visual media in meetings.Future research should incorporate more positions within software development and investigate software meetings including people with varied or mixed abilities.

4. 3 . 2
Avoiding Disclosure.Most participants said that they only want to disclose their disability when necessary or as a last resort.P3 shared, "I don't like revealing [my disability] to people if I can avoid it" (P3), and P7 stated, "[I] try to keep it [disability] as far away from the point of the meeting as possible." Participants used a variety of strategies to avoid disclosure: access façade and conversational nudges.

Figure 2 :
Figure 2: Access Labor of Disclosure for Each Meeting

Table 2 :
[78]ing Details.Types of meetings are abbreviated: PM (Project Management), Consult (consulting with colleagues), and SE (Software Engineering, meetings that are directly related to development of the software product).Abbreviations for software include VC (Video Conferencing Software, e.g., Zoom or Microsoft Teams) and IDEs (Integrated Development Environment, e.g., Git, and Visual Studio Code).Many of these meetings come from the Agile process[78].