The Information Technology (IT) sector is a growing part of the global economy. Despite the COVID-19 pandemic, hiring freeze, and layofs [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 efective software development, as they foster real-time conversations and collaborative problem solving [37], directly infuencing 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 identifed 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 refexive 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 fndings, 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 frst 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 eforts 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.
Due to inaccessible tools, ableist attitudes, and a lack of accommodations, people with disabilities often have more difculty 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 difcult 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 frst 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 efects 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 efort 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.
BLVSPs, as a particular subset of all BLV and disabled professionals, have been the topic of several specifc 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 specifcally 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 Huf 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 specifc challenges faced by BLVSPs in software development meetings.
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 efectiveness 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 workfow [82]. Despite meetings often being perceived poorly, research shows that some types of meetings in software development are considered productive, specifcally those in the specifcation, 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.
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 specifcally 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 difcult 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] identifed 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 frst 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 refnement meetings [70]. Such meetings not only involve the presentation of visual content, but also constant updates (e.g., modifcations 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.
We recruited 26 people who identifed 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 specifc 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 confdentiality of our participants' information, we anonymized identifable information, including name, age, and job titles. We reclassifed 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. Specifc participant demographics are explained in Table 1.
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 of 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).
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 frst, second, and third authors analyzed the same fve transcripts through engaging in open coding [18] and discussing initial emerging themes. Thereafter, the frst three authors met three times while analyzing the data and iteratively discussed emerging themes across the fve transcripts [18]. Authors engaged in axial coding [18], analyzing the remaining 21 transcripts in parallel, meeting frequently to discuss fndings 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.
Meetingsfoot_0 for BLVSPs provide opportunities for "exchanging ideas with other people in real time" (P13), support interpersonal connections, and foster efective 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 diferent perspectives about disclosing their disabilities in meetings.
4.1 The Accessibility of Software Development Meetings 4.1.1 Types of Sofware Development Meetings and Accessible Meetings. Out of a wide range of software development meetings that our BLVSPs participate in (see Table 2), certain meetings, such as upper management meetings and daily standups were largely accessible since they are inherently conversational. P22, an accessibilityspecialist in upper management, had spent "almost all of my time in the weeds" but has "the ability now to have these higher impact meetings" which avoided accessibility issues. P6, who has low-vision, fnds it easier to be closer to the screen in smaller meetings, which tend to be more accessible than larger meetings (P6, P10, P13, P26). ID Job Position Experience (yrs) Organization Type Self-Disclosed Vision Status Age Gender P1 Software Engineer 1-5 Finance light perception 26-30 M P2 Software Engineer 6-10 Media totally blind 31-40 M P3 DevOps Engineer 1-5 IT legally blind w/ tunnel vision 31-40 M P4 Consultant 6-10 Consulting 2% vision 31-40 M P5 Software Engineer 1-5 IT low vision 26-30 W P6 Business Owner 1-5 Non-proft legally blind 20-25 W P7 Accessibility Specialist 1-5 Finance completely blind 20-25 M P8 Software Engineer 6-10 IT totally blind 26-30 M P9 Technical Executive * 16+ Finance blind/low vision 51+ M P10 Accessibility Specialist 6-10 Finance some light perception 51+ M P11 Software Engineer 1-5 IT 20/150 corrected, blurry 26-30 M P12 Product Manager * 11-15 IT completely blind 31-40 M P13 Software Engineer 16+ IT totally blind 51+ M P14 Solutions Analyst 1-5 Higher-ed limited feld vision N/A W P15 Software Engineer 6-10 Non-proft totally blind 31-40 M P16 Accessibility Specialist 1-5 IT totally blind 31-40 M P17 Accessibility Specialist * 16+ Finance completely blind 51+ M P18 Accessibility Specialist 6-10 IT totally blind 31-40 M P19 Software Engineer 6-10 Outsourcing totally blind 31-40 M P20 Software Engineer 1-5 IT totally blind 26-30 M P21 Software Engineer 1-5 IT totally blind 20-25 M P22 Accessibility Specialist * 16+ IT visually impaired 51+ M P23 Accessibility Specialist * 16+ IT completely blind 51+ M P24 Software Architect 11-15 IT low vision 31-40 M P25 Accessibility Specialist 6-10 IT nearly blind w/ shape/color perception 31-40 M P26 Accessibility Specialist 1-5 Healthcare totally blind w/ light perception 31-40 W Table 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 specifc position information. The asterisk * signifes positions of management.
Certain software development meeting activities (with sufcient verbalization) were also reported to be accessible. For example, P2, who both goes into ofce 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 benefcial 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 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 insufcient 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 magnifcation 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 signifcant accessibility issues. Multiple participants shared that while driving pair programming
Meeting Name Meeting Type What Happens in Meetings Duration (mins) Perceived Accessibility Software Used Standup PM daily updates regarding progress and blockers 5 to 90 accessible: conversational until inaccessible software is involved PowerPoint Retrospective PM discuss successes and areas for improvement in prior sprint 60 to 90 inaccessible: no additional workarounds to visual content Lucid Ad hoc PM, SE spontaneous meetings about software development 30 to 120 usually accessible when conversational, inaccessible with Jira Jira, etc. Design Meeting PM e.g. defne specifcations, identify and design software architecture and features 60 to 120 accessible with verbalization, inaccessible when diagramming is involved Miro, Lucid, PowerPoint, VC Sprint Planning PM assigning tasks (tickets) to developers 60 to 120 accessible when conversational, inaccessible when Jira is involved Jira Demo SE demonstrate software, features, updates, etc. 30 to 120 can be accessible with description, inaccessible with visual content VC Pair Programming SE two people work on one code base simultaneously; the driver writes code while the other co-pilots 30 to 60 accessible while driving, inaccessible when co-piloting IDEs, Git One on one Individual scheduled time with superior or peer 15 to 60 accessible: usually conversational VC Software Troubleshooting SE debugging and troubleshooting with colleagues 30 to 90 accessible if conversational, can be inaccessible if code base is not local or if product is inaccessible IDEs, Git Sprint Review PM analyzing progress with product focus at end of sprint, before retrospective 60 to 120 inaccessible due to visuals (e.g., UX walkthrough) Jira, PowerPoint Customer Meeting Customerfacing meeting with customers for consultations, design requirements, etc. 30 to 60 variable, but usually inaccessible. Depends on customers (e.g., clients bring visual materials) PowerPoint Code Review SE review code with group, approve code 30 to 60 accessible without screen share IDEs, Git Scoping SE estimate level of efort for whole features or user stories, not individual tickets 30 to 60 accessible until inaccessible software is involved VC Brainstorming SE generate ideas with team members through open discussion 60 to 120 accessible with conversation, until inaccessible software is involved Miro Ofce hours Consult open hours for consulting with peers, colleagues about software 30 to 60 accessible with conversation, until inaccessible software is involved VC Backlog Refnement PM organize backlog of stories and assigning tickets to following sprint 30 to 60 accessible with verbalization. Usually inaccessible due to software Jira Table 2: Meeting 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]. "works well enough as long as [sighted colleagues keep] a constant fow of dialog as they're programming" (P1), co-piloting remotely when the sighted colleague is sharing screen and "scrolling around and asking questions about diferent parts of the code base... is the bane of what I do" (P3). Both the driver and co-pilot agree that it is easier if the BLVSP drives because "I'm in control, I know what the other code is I'm working on... if they're driving, they have to do a lot of verbalizing" (P2).
Many software meetings, such as design meetings, architecture meetings, and whiteboarding activities, revolve around visual media and diagrams such as fow 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 fowcharts] 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 "clarifcation 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 difcult 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 difcult (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 fle at the same time as everyone that's sighted who gets to look at it in the standups. "
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 fnding 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 defnitely 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 diferently: "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.
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 feld" during meetings. Perhaps most frustrating for our participants was that, even when they put in the extra efort, 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 frst like ten minutes. Then, everyone else was just able to navigate the service a lot quicker than me... 'is [this meeting] the most efective 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 feld, 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.2 During 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 fy. " 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 of 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 refnement 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 diferent workarounds to deal with inaccessible screen share during their meetings. On top of using screen magnifcation 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 eforts 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 stuf 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 diferent way. " Sighted Assistance. Participants occasionally relied on their sighted colleagues for assistance. P7 mentioned that when people worked on visual materials like fowcharts 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.3 Afer 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 fll 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 "of to other meetings" (P23).
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 specifc. " 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 difcult over time for some team members. P1 explained, "I do try to explain to my teammates what I need, but it's difcult to change your ways and multitask, if you aren't used to maintaining that constant fow 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 diferent 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)
Participants described expending a great deal of energy constantly weighing the tradeofs of disability disclosure to colleagues, supervisors, external vendors, and clients. P4 noted that "it's a tradeof, 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.
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 of 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 ofer "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 fll 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-fy work. "
Another tactic to "sideswipe the disability conversation, " demonstrated by P7, was to insinuate he was looking at a diferent 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 fnd 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 diferent 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 fips questions directed at him back towards the customers whose slides have inaccessible visuals, letting him of 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.3 Reluctantly 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. "
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 fxate on his disability. P13 described diferent 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 signifcant 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 diferently. "
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 defnitely refects 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 amplifed when disclosure could lead to lost business. As P12 reported, "I'm terrifed of a customer's disbelief that a blind person could do something would infuence 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: "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 ofine 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 confdent 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.2 Future 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 Artifcial 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 of 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 flter 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 confdential 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 magnifcation 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 magnifcation 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.3 Meeting 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 eforts, 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 ofce 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 ofce team...'" (P18)
In contrast, P5 explained that at her company:
"you especially have to do everything online. Not through a person frst. And there was no option to even list exactly what I was experiencing. ...there was no option for me to fll out that I need [meeting] fexibility. "
P5 was unable to fll out her company's accommodation form, since her condition did not ft into one of the predefned 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.
Though much attention has been paid to the accessibility experiences of BLV programmers, this is the frst research study to explore the accessibility of software development meetings from the perspectives of a range of BLVSPs. Here, we discuss how our fndings corroborate some of those from existing literature on (1) accessible software development and (2) accessible remote meetings, and ofer 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 difculties 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 fndings 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 fndings 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 fndings that are particularly new in the context of existing literature, either by providing a new perspective altogether or by situating existing fndings in the context of software development meetings, which have their own peculiarities and thus introducing challenges for BLVSPs. We organize these fndings 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 fndings for researchers.
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 afecting 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.
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 diferent 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.
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.
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 fnished; each new meeting could be another decision point around disclosure. Figure 2 refnes our collective understanding of access labor into what amounts to a small decision model, indicating the diferent nuanced layers of labor included within the access work of disability.
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 benefts 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 objectifed 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 diferent BLVSPs bore a greater or lesser burden. Although participants mostly chose to disclose disability only when necessary, everyone had diferent 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 aford them more powerful, "big voices" (P9).
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, sonifcation 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 difcult 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.
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 magnifcation and totally blind people who use screen readers differ signifcantly. 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 specifcally 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 diferent types of visual disabilities in diferent contexts of meetings and work.
All of our participants resided in the United States of America, Europe, or India, thus our fndings 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 afect our participants' work experience.
We included low-vision professionals in our study, which significantly enriched our fndings 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 identifed benefts 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 specifcally 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 specifc positions varied.
We investigated the accessibility of software development meetings for BLVSPs. We conducted semi-structured interviews with 26 BLVSPs and identifed four novel themes: (1) certain meetings and activities were prone to accessibility challenges, (2) participants performed signifcant 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 fndings from previous literature that also hold true in software development meetings, but to this we add several unique fndings. 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 fndings 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 tradeofs 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.
Many of our participants worked remotely and the majority of their meetings were remote. Therefore, in our Findings and Discussion, we use the term "meeting" to refer to remote meetings, unless specifed otherwise.