Accessibility issues in establishing awareness on remote collaborative software development

The COVID-19 pandemic impacted the work dynamics of software development teams with the sudden adoption and subsequent continuation of remote work. New practices were adopted to maintain relationships be-tween team members, mediated by computational tools. However, this presents an additional challenge for people with visual or hearing impairments. This study identifies different experiences of professionals with and without these disabilities in maintaining awareness when working remotely. To achieve this objective, 93 responses were collected through an online form from professionals, with and without visual or hearing impairments, and the supervision of a collaboration tool, among the most mentioned due to the lack of accessibility for people with visual impairments, using the Semiotic Inspection Method with Screen Reader (MIS-LT). The results point to different groups’ experiences with the use of collaborative tools on the social aspects of remote collaboration and an assessment of the communicability and accessibility of the inspected tool


Introduction
The COVID-19 pandemic has impacted the world in many ways, including the work dynamics of software development teams.With the sudden migration to the home office and subsequent continuity in remote work, new dynamics for relationships were established, mediated entirely through computational tools [Lisbôa et al., 2021; Ralph et al., 2020; Ford et al., 2021; Miller et al., 2021].
In the remote scenario, software construction -as an essentially collaborative process -relies on the intermediary of tools to assist the activities developed.Considered a critical factor for the success of collaborative work, the concept of perception, or awareness, refers to understanding the activities of others while providing the context for your activities [Dourish and Bellotti, 1992].
For people with visual or hearing impairments, keeping up with the rest of the team in remote environments can present specific challenges related to both the technical and social aspects involved in the collaboration process [Tang, 2021; Pandey et al., 2021].
We sought to establish a parallel between people with disabilities and the experience described by people without disabilities, including their perceptions about tools and difficulties, to validate the following hypothesis: people with visual or hearing impairments face different experiences and challenges for maintenance of awareness in remote development teams when compared to people without disabilities.
Previous studies have already dealt with factors related to the accessibility of tools for remote collaboration Ang et al. [2022], the inclusion of people with disabilities in development teams [Gomes Filho and De Toledo, 2015; Albusays and Ludi, 2016; Silva et al., 2020], and the interaction of people with disabilities in development teams remote development [Tang, 2021; Pandey et al., 2021].However, the analysis of the maintenance of awareness, a fundamental aspect of remote collaboration among people with disabilities in development teams, still requires further investigation.
The relevance of this study is supported by the growing adoption of the hybrid or fully remote work model in Brazil [ IDC Brasil, 2022], the increased inclusion of people with disabilities in the technology market [Revelo, 2021] and, as mentioned before, the need to understand aspects related to remote collaboration and accessibility within software development teams.
To achieve these objectives, 93 quantitative and qualitative responses collected through an online questionnaire filled out by people who work remotely with software development in Brazil were analyzed.People with visual and hearing impairments and those without these disabilities participated.With the results, it was possible to identify different experiences for building awareness in remote teams and how these perspectives affect collaboration from technical and social aspects.
The survey results showed that people with hearing impairment did not report significant problems updating the progress of their tasks for the remainder of the software development time.This audience commonly points out issues related to communication, especially when transcribing audio in meetings.The tools used to maintain awareness as a direct obstacle were not mentioned but seen as allies in this activity.About the responses of people with visual impairments, some tools were mentioned, pointing out a lack of accessibility and, consequently, the difficulty of using them without help from third parties.Classifying them in the 3Cs model from Fuks et al. [2011], Microsoft Teams is indicated as a communication tool, Figma as a cooperation, and the most cited was the Jira coordination tool.
The Jira tool [Atlassian, 2017] is often used to facilitate task management in software development teams.Tasks are organized into cards, with information such as deadlines, small activities to be carried out, possible impediments, the person responsible, and intersections with other tasks.Therefore, each task to be done must contain enough information to keep development teams constantly updated on what is being done and by whom.
This work is an extension of Rocha et al. [2023] work, where an inspection was carried out on the Jira tool, the most cited among people with disabilities, to evaluate communicability and accessibility in using four activities commonly used to ensure awareness of the tasks performed by the team.As most interviewees who mentioned Jira are people with visual impairments, we chose to use the MIS-LT de Carvalho et al. [2019] method for this evaluation, as it includes the possibility of evaluating the tool through the screen reader.
The rest of this paper is organized as follows.The 2 section presents related work, while the 3 section presents the theoretical framework.Section 4 details the methods used in this work.Subsequently, Section 5 describes the results obtained from the research, followed by Section 6, which addresses the inspection of the collaboration tool.Finally, Section 7 presents the discussions and contributions of this research, culminating with the final considerations in Section 8.

Background
Next, the contextualization for Awareness focused on remote collaboration is involved, followed by the importance and relevance of the inclusion of people with disabilities in times of software development and a general approach to inspection of accessibility and communicability.

Remote Collaboration and Awareness
In this work, we will use a sociotechnical definition [Cruz et al., 2012] of collaboration: the 3C Model [Fuks et al., 2011].This model, see Figure 1, is systematized by an interactive cycle between 3 well-established modes of collaboration: communication, cooperation, and coordination [Cruz et al., 2012].According to Fuks et al. [2011], despite the established dimensions, "the Cs interrelate for collaboration to occur", getting awareness of the role of promoting feedback to the individual about their actions and the actions of other team members.Fuks et al. [2011] In the relationship between the 3C's, communication generates commitments managed by coordination, which organizes tasks for cooperation, helping to manage conflicts and optimize the relationship between people, avoiding loss of communication and cooperation efforts.Cooperation generates more demand for communication, thus closing and restarting the iterative cycle of collaboration.In this cycle, awareness provides feedback for the actions of the users and acts as an essential mechanism for reducing waste in collaborative efforts [Cruz et al., 2012].According to Steinmacher et al. [2010]: • Communication concerns how messages are exchanged between people.Consider gaps, ambiguity, and the need for effort to understand, establish, or continue a conversation; • Coordination consists of mechanisms for people to manage themselves or be aware of activities and their effects on collaboration; • Cooperation is about interaction in shared space or artifacts synchronously or asynchronously.Drury and Williams [2002] structured awareness definitions for users in synchronous collaborative applications.Related to awareness applied to the 3C Model in remote or hybrid software development teams is group structural, defined by knowledge about things, such as roles, responsibilities, positioning and location, and group interactions.Informal deals with the general notion of what other people are doing; peripheral, where people know approximately what others are doing; social is connected to information about a person's tasks in a shared environment; task-oriented to achieve a shared task related to the activities carried out and; workspace which deals with updated knowledge of interactions of other participants with the shared workspace and understanding of who is working on what.

Accessibility and Inclusion
Considering that among the users of a computer system, we can include people with disabilities who interact through assistive technologies, the intercession of HCI with Collaborative Systems must cover not only aspects related to the concurrent use of files or the architecture necessary to connect those involved remotely, but also all aspects of quality in HCI: usability, user experience, communicability, and especially accessibility.
According to Barbosa et al. [2021], "The accessibility criterion is related to the ability of the user to access the system to interact with it without the interface imposing an obstacle.".Including people with disabilities in software development teams crosses social issues, human rights, legal obligations, market needs, and competitive advantages, among others.Therefore, far beyond end users, these people can and should be considered as protagonists, also of remote work in this scenario, considering their perspectives and specificities.
When looking at the RAIS Information Panel [Brasil, 2022] with data from 2021, only for the CNAE 2.0 class "Development of Custom Computer Programs", an inversion can be seen between the percentage of people with visual impairment (25.42%) and hearing (14.03%), when compared to the total numbers of people with disabilities employed.
Even after the end of the social distancing measures promoted by COVID-19, in 2022 in Brazil the maintenance of the totally remote or hybrid work format was observed, the sum of these two being 75% against only 25% of face-to-face work [ IDC Brasil, 2022].This factor reinforces the importance of analyzing aspects of inclusion and accessibility for professionals who work in this format.Communicability is linked to using tools in routine work tasks and accessibility when using these tools.

Communicability Inspection
The MIS-LT [Carvalho, 2021] is theoretically based on the semiotic inspection method (MIS), defined by semiotic engineering theory.Based on the book from De Souza [2005], the idea is guided by the characterization of how the designer designs and interprets the execution of tasks in a system based on the concept of metacommunication with the user through a communication analysis.
Therefore, the MIS enables the assessment of communicability, seeking to find ruptures in communication based on the analysis of the system's interfaces and the possible interactions that users carry out with it.The steps determined for accessibility inspection using MIS-LT are similar to those covered by MIS.Therefore, there is a need to carry out an initial stage contemplating the scenario and scope, followed by the analysis of metalinguistic signs, static signs, and dynamic signs.Next, the locations of contrasting the metamessage and appreciating communicability are carried out.All steps, except the environment preparation step, must be performed simultaneously without the screen reader and with the screen reader.
Thus, MIS-LT aims to make the MIS usage scenario viable through the combination and use of assistive technologies, in this case, the screen reader, to evaluate the metamessages transmitted by the designer and the interpretation that the user has together.With the ruptures found in communication.Therefore, the inspection aims to verify the accessibility and communicability disruptions of the Jira tool, with four researchers using MIS-LT, defining the proposed scenarios and proposing accessibility improvements for using the device with a screen reader, especially for people visually impaired software developers.

Related Work
Recent research addresses different aspects of remote collaboration, investigation of tools from the perspective of people with disabilities, analysis of applied survey data and accessibility in software development teams.
Gomes Filho and De Toledo [2015] developed an action research that promoted the inclusion of a visually impaired person in a software development team.Based in Brazil, the group operated in person and used agile development practices, many based on visual management.Through adaptations to the environment and the methods used, it was possible to enable the participation of members with visual impairments at all stages of development.In this study, interactions mediated by computational tools were not analyzed.Albusays and Ludi [2016] researches accessibility among developers with visual impairments, identifying their needs, challenges and strategies for executing software engineering activities.In this research, aspects of remote collaboration were not considered.Among the challenges identified are: low accessibility in the IDEs used, incompatibility with screen readers and difficulty in navigating large amounts of code.
Tang [2021]'s work evaluated the interaction of accessibility tools with tools that allow collaborative practices such as video calls, screen sharing, and text editing.The author considered the experiences and challenges of 25 people with disabilities (visual, auditory, motor, and neurodiverse) from the United States who work in different areas of work.Neither characteristics relating to software development teams nor awareness were considered.Pandey et al. [2021] investigated how visually impaired programmers experience collaborative activities, including the challenges they encounter, how they overcome them, and the implications of these challenges for individuals and teamwork.The 23 interviewees work on four continents: American, European, African, and Asian.The article reports the mechanisms used to carry out coding activities, from the construction of the development environment to the practices of code review and pair programming.The authors should have emphasized the use of remote collaboration tools such as those used for task management and communication (e.g Jira, Teams, Slack), not delving into the challenges encountered in their use and interaction with other team members.
In a post-pandemic scenario, where computer-mediated relationships have become more common, Ang et al. [2022] address considerations of people with hearing impairment (deaf or hard of hearing) who communicate through sign language (including hearing interpreters) on video conferencing platforms.Challenges and accessibility barriers for this audience were identified, new design opportunities were discovered, and practical guides were created to improve accessibility.Nascimento et al. [2022] carried out a quantitative and qualitative analysis through a questionnaire aimed at people with visual impairments who are software developers and carried out accessibility inspections on standard tools in ev-eryday software development, as mentioned by the respondents.However, this work does not address remote or hybrid work issues, and the 3C model is not considered.Carvalho et al. [2019] proposed an adaptation of the Semiotic Inspection Method to analyze aspects related to accessibility for visually impaired individuals who use screen reader tools.The purpose of this study is to contrast the metamessage received by users with and without blind disabilities, to identify possible problems related to system communicability.Carvalho et al. [2021] conducted a case study to evaluate aspects relating to communicability on the TudoGostoso website using the MIS-LT method.This analysis considers the accessibility and communicability of the metamessage sent from the designer to the users with and without screen readers, identifying potential problems in website communication.

Study Objetive
Gomes Filho and De Toledo [2015] Action research to include people with visual impairments who work as software developers in all phases of development Albusays and Ludi [2016] Evidence of low accessibility in IDEs used in software development Tang [2021] Evaluates the interaction of accessibility tools with video calling tools and their resources from the perspective of people with disabilities This study presents the barriers faced by people with disabilities in software development teams based on data found in a survey, which predominantly reports a lack of accessibility in software development tools for people with visual impairments.Focuses on the impact of accessibility variables on establishing awareness to contribute to the construction of inclusive environments and tools for professionals working in the construction of software products, highlighting an inspection of communicability and accessibility in the collaboration tool most related to accessibility issues, starring a person with visual impairment inserted in a moment of software development to carry out tests using MIS-LT, to understand the ruptures in communicability closer to everyday life in times of development.The main differences between the related work and the current work are shown in Table 1.

Methods
The following topics cover the analysis of data obtained in the survey response, exploring the problems highlighted by people with disabilities, and the use of MIS-LT in inspecting the collaboration tool.The research involved the participation of volunteers.By Resolution 510/2016 of the National Health Council (CNS) art. 1 -public opinion survey with unidentified participants; this research did not need to be registered with the Brazilian Research Ethics Council.It is worth noting we keeping the participants' privacy and data confidential using the data collected exclusively for research and analysis purposes of the parameters investigated in this work.

Survey
The methodology used was bibliographical research and quantitative and qualitative empirical research.The target audience included Brazilian professionals who work with software development in remote teams and whether or not they have visual or hearing impairments.Initially, a pilot questionnaire was prepared and submitted to identify limitations and possible improvements -including accessibility -for people using screen readers and people who preferably communicate using sign language.One blind person who uses a screen reader and one Brazilian sign language translator helped with this validation.Adjustments were implemented to make the texts more objective and make the consent form available via a link to make it easier to read.The survey with the questions prepared is available at Melo [2024].
One hundred two responses were collected in two periods of approximately one week (June 2022 and December 2022).Of these responses, eight were discarded because they were not working remotely.Among the 93 valid responses, 48 were from people without disabilities, 12 with hearing, and 33 with visual impairments.The dissemination of the research and recruitment of participants was carried out through posts on social networks (WhatsApp and Linkedin) with requests for sharing by people in the target audience to enhance reach through the approach of snowball.
The final questionnaire contained ten questions.The first four are about personal aspects: your role in the development team, seniority, whether you are interacting remotely, and whether you are a person with visual or hearing impairment.The following questions focused on the participants' experience of maintaining awareness in a remote environment.Two quantitative questions sought to measure, through the Likert scale, the ability to maintain awareness in the remote environment and the support of the tools used for this purpose.In this context, evidence of awareness maintenance is related to group-structural, informal, peripheral, social, taskoriented, and workspace awareness.Specifically, respondents were asked to respond to their self-assessment regarding two statements.To facilitate understanding, the expression being up to date or the Portuguese term, percepção, was used instead of the English expression awareness: (a) I can stay up to date with the activities that are being carried out by my team; The tools that are used to monitor my team's activities allow me to have a complete perception of everything that is happening.
It was not necessary to have prior knowledge of the 3C model's concepts.Based on their own perceptions, the intention was to analyze how the concepts were related to the respondents.
Participants were also asked to inform the tools they used to manage project activities and describe in their own words the main difficulties they encountered in maintaining awareness of their teammates' actions.To conclude, a last open question sought to collect other problems and support points in the remote work routine.
To analyze the qualitative results, the open coding process was used to categorize fragments into codes to maintain the meaning of the information expressed [Charmaz, 2009].The coding was done by the first author, who identified themes related to the regulations.The quantitative data were analyzed to obtain descriptive statistics.

Semiotic Inspection Method with Screen Reader (MIS-LT)
To use the MIS-LT it is necessary to carry out six steps, defined based on the original MIS, where step 0 consists of determining the objective of the inspection, in addition to defining the scope of the scenarios to be executed, and finally, identifying the target audience to which the review will be directed.Next, steps 1, 2, and 3 consist, respectively, of the identification and analysis of static, dynamic, and metalinguistic signs.
Step 4 evaluates the contrast between the messages generated in the three previous steps.Finally, step 5 condenses the information and conclusions, proposing improvements and showing the positive and negative impact found in the inspection.These steps are defined from the original MIS.Through this inspection method, it is possible to collect communication disruptions and, consequently, identify the access barriers faced by people with visual impairments to interactive systems.The dynamics of including people with visual impairments in the MIS-LT strengthens the evaluation of an accessible approach and reduces biases that can affect the capture of communicability disruptions.
To carry out the inspection, a Dashboard was created in Jira in a free account, involving the researchers of this work, simulating an environment for monitoring tasks in software development teams, and defining the researchers as team members.The data imported into this Dashboard was extracted from another collaboration tool, also used by the same researchers to control their activities.
MIS-LT was applied to Jira by four researchers.They are referenced in this work with the code P1 to P4. P1, P2, and P4 had experience in carrying out systems inspections and semiotic engineering, in which P1 carried out previous evaluations on mobile applications using as a basis a set of design considerations built to improve accessibility.Furthermore, P2 and P4 used MIS, MAC, or MIS-LT in previous projects to evaluate the communicability of web and mobile applications.P3 is a person with visual impairment and a systems developer, user of a screen reader, and without experience in applying evaluation or inspection methods.For this reason, P1 and P2 explained the MIS-LT and followed the inspection with a screen reader and P3.
The inspections were carried out during August and September 2023.At first, P1 and P2 carried out the communicability inspection without the screen reader.Then, P3 carried out the inspection mediated with the screen reader, supported by P1 and P2.Finally, P4 aimed to observe the interaction process with the screen reader to discuss the barriers faced by P3.It is worth mentioning that this paper is not part of the MIS-LT method, and P4's observations did not influence the final inspection result.

Survey's Results and Findings
In this section, the survey's results will be presented using demography data, participants' perceptions of awareness, and their experiences in maintaining the knowledge of team activities in remote interactions.

Results
The results are concentrated on the analysis of survey data, which are categorized into participant information, awareness perspective, and difficulties reported by respondents.

Survey's Participants
The first part of the questionnaire sought to identify the profile of the informants through their characteristics regarding the type of disability (or not), seniority, and the role they play in software development.As for the roles played by the participants, the number of developers was the most significant, representing 73% of the respondents and having the participation of 3 groups of physical characteristics (Figure 2, a).Of the other roles represented, only the Quality Analysts had participants from the three physical characteristics studied, with the other roles covering only one or two, as we can see in Figure 2 (b).The survey reached people at all levels of seniority (junior, mid-level, and senior) and obtained responses from the three groups of physical characteristics distributed across the profiles, as can be seen in Figure 2 (c).

Awareness Self-assessment
Regarding the feeling of "updating the team and being updated on the activities being performed", that is, awareness, it was possible to collect qualitative and quantitative data from the participants, the latter presented in Figure 3.
Close values were identified among the three groups for the feeling of updating (Figure 3, a), with the group that feels most updated being formed by people with visual impairment, followed by people without disabilities.
Regarding the role of tools in maintaining awareness, a more significant difference can be seen (Figure 3, b), where people with visual impairment are the group that evaluates receiving less support from tools for this purpose, followed by people without disabilities.Among the tools used to manage project activities, Jira was the most cited (appearing in 73% of responses), followed by the spreadsheet (with 34% of mentions), Microsoft Planner (8%), Azure Boards (7%), GitLab and Trello (both with 5% of citations).Other tools had less representation.
Cross-referencing the data on the perceived help of the tools to maintain awareness with the five tools most cited by respondents, it is possible to notice variations depending on the characteristics of the researched group.People with visual impairments rated GitLab as the worst tool and Azure Boards as the best.Among people with hearing impairment, there was slight variation, and all the tools mentioned received a rating equal to or above four on the Likert scale.In the group of people without disabilities, Azure Boards was the worst-rated tool, and Git Lab was the best-rated.

Difficulty and Support
The qualitative analysis of the difficulties and support points presented by the respondents was carried out on three questions.The first question addressed the difficulties in keeping up to date, that is, the awareness of colleagues' activities (question a in Section 4.1).
When analyzing the responses, 12 different codes were created (Figure 4).The group that presented the most minor difficulties was those with hearing impairments, and people with visual impairments found it most challenging to keep up to date with their team in the remote work model.For people with disabilities in general, the accessibility of tools was the most cited difficulty in keeping up to date with the activities being carried out by the team.
The perspectives brought about accessibility, however, varied depending on the characteristics of the respondents.People with hearing impairment mentioned interactions via video conference, reporting difficulties with the quality of the automatically generated subtitles.People with visual impairments mentioned the inadequacy of task management tools for use with the screen reader feature.
Among the task management tools named in this group's responses, Jira was the most mentioned (7 mentions), in addition to Trello and ShortCut, with one mention each.Other tools for drawing, communication, and remote cooperation were also cited as accessibility obstacles, such as Miro, Figma, and MS Teams.One participant mentioned, "What limits me from staying current is that tools like Jira, Short-Cut, Trello, and Figma are inaccessible enough to provide independence and autonomy." For people without disabilities, this item was mentioned by a single respondent.However, this informant acts as a test analyst alongside a person with visual impairment.According to him, the difficulty encountered is: "Management tools where the reader does not verbalize the content." The second question sought to understand the difficulties in updating the team about their activities (question b in Section 4.1).
In the group of people without disabilities, 33% declared that they did not experience difficulties in keeping the team updated on their activities (Figure 5), with monitoring tools Regarding difficulties, the accessibility of tools was mentioned by both groups of people with disabilities, being mentioned more than once in each group.They highlighted the main characteristics of the assistive technologies they used: automatic caption generator (hearing impairment) and integration with screen reader (visual impairment).
People with visual impairments named the tools Jira and MS Teams as poor examples of accessibility.In this group, participants mentioned the need to make several adaptations to carry out their activities: "Teams and Gmail on the web are great examples of lack of accessibility.We were only able to use it because we made several modifications (workarounds) to be able to follow" [the rate of use of participants without disabilities].
Only people with hearing impairment reported communication difficulties, citing the quality of the subtitles generated and obstacles when there are many people in virtual meeting rooms or, in written communication, when they have to consume confusing and long-winded texts.
Some aspects of social relationships listed as making it difficult to maintain the team's awareness regarding the activities carried out refer to insecurity towards colleagues and a lack of empathy or otherness.These situations were brought up by people with visual impairments, who were also the The difficulties most cited by people without disabilities in updating colleagues about the activities they are performing reflect issues intrinsic to the remote work format, such as lack of time and availability or engagement for interactions.They were also the only group that brought up the lack of personal contact with colleagues, also mentioning the closed cameras in video conferences: "the eye contact, some people do not like opening the cameras in meetings.".
Finally, an open space was offered to report other difficulties or support encountered by participants in carrying out their activities remotely: I would like to express any other difficulties faced or important support points for your daily life within your work context.
When asked to express other aspects of remote collaboration, respondents from all three groups cited new points of challenge and support in their daily lives.Table 2 presents the data brought by each group, where it is possible to see that people without disabilities bring problems already reported in the literature on remote work.It is important to highlight the perception of a visually impaired person regarding the inclusion of the professional in the team: "generally, people decide to leave the disabled programmer aside, always in the last plan.It sometimes leaves us stopped." Regarding the positive aspects, in this same group, the importance of receiving support from their team and company was mentioned through welcoming, empathy, and help in the use of tools that are not very accessible: "I would like to highlight the importance of team support itself, despite the tools or methods used.An empathetic team is even more important than the tools used.Team awareness is critical in this context, and the company where I work works hard on this".People with hearing impairment did not mention positive aspects, and people without disabilities mentioned communication in virtual meetings (especially the daily meetings), voice channels, and instant messaging positively.

Group
Difficulties Hearing Impairment -Cameras turned off make it difficult to understand in virtual meetings, as they do not allow lip reading; -In the remote environment, there is a need to schedule meetings, when in person, it is easier/quicker to interact with the team.Visual Impairment -Lack of accessibility of tools used for dynamics, gamification, work meetings, and applications used by the company's personnel department; -The emphasis on visual communications, with images and colors, without a descriptive alternative.No Disability -Lack of preparation for remote work, in terms of infrastructure and incentives (connection problems, lack of support for hardware issues, unavailability of suitable tools for remote collaboration, and little financial support for the home office); -Lack of team training and engagement for remote work.

Findings
From the analysis of quantitative and qualitative data obtained in the research, it was possible to identify the diversity also portrayed in how people without and with visual or hearing impairments experience their remote interactions in software development teams.
It was possible to observe that the three groups participating in this study experienced different challenges in updating the team and keeping colleagues updated about their activities, validating the hypothesis as accurate: "People with visual or hearing impairments face different experiences/challenges in maintaining awareness in remote development teams when compared to people without disabilities".Thus, some perspectives of maintaining awareness for people from different groups were consolidated in each aspect of the 3C Model (described in Section 2.).
In Table 3, Table 4, and Table 5, the perspectives of the three groups researched are consolidated: people with hearing impairment, visual impairment, and those without disabilities.Groups that least recognize tool support do so for different reasons.Among people with visual impairments, the difficulty is concentrated in activity management tools due to their incompatibility and complexity with screen readers.People with hearing impairment point to meeting caption generators as the point of most significant difficulty regarding accessibility, with this group benefiting from written records in activity management tools, while for people with visual impairment, virtual meetings take on this role.
In order to use the tools that the rest of the team uses, people with visual impairment spend time and energy beyond what is traditional to carry out their activities, which can interfere with their productivity as perceived by other people.On this subject, P60 mentions: "I spend more time finding the item corresponding to my activities to update the status, but nothing I cannot do; it just takes me longer." The empathetic positioning of colleagues, wellestablished organizational communication channels, meetings, and dialogue help people with disabilities maintain awareness.Despite the communication difficulties cited by the group of people with hearing impairment, this was also the group that brought the support of other team members as a positive factor in sharing the tasks performed, illustrated by P54: "a squad is very welcoming and willing to help me with my difficulties".
For people with visual impairments, the possibility of working remotely represents opportunities to improve work dynamics, as mentioned by P68: "In fact, I had difficulties working in person.Now that it is remote, there are no more boards, paper, post-it notes, etc." and P60: "and accessibility (I can work at any company without leaving home, just in my room, with my computer, so I feel very safe and autonomous)".A factor not mentioned by people with hearing impairment, which contrasts with the mention only by people without disabilities, about the lack of personal contact as a challenge when working remotely.

MIS-LT Inspection
In this section, the steps and the results of the perfomed MIS-LT inspection are presented.The steps consists oh the analysis of the settings defined with and without a screen reader and the contrast of the metamessage of each sign.Then, the overall contrast of the metamessage, with and without the screen reader, and the final inspection evaluation and inspection discussion.

Stage 0: Preparation
The inspection on Jira was carried out using the screen reader NVDA version 2023.2.Researcher P3 configured this tool with the eSpeak NG synthesizer, in Brazilian Portuguese, with the Iven3 variant and 55% reproduction speed.Both inspections, with and without a screen reader, were performed in Google Chrome browser.The inspection objective was to identify Jira's communication breakdowns in task management capabilities in software development teams.These results are expected to provide a better understanding of Jira's accessibility issues for developers with visual impairments.
Based on the survey's results, an informal inspection was carried out to confirm the problems related to accessibility highlighted by professionals with disabilities and to build test scenarios based on tasks commonly performed by members of the software development team.
Thus, the scenario created for this inspection describes visually impaired developers working on remote, mixedability software development teams and use Jira as the primary tool for maintaining awareness of the activities carried out.This scenario was segmented into three tasks commonly performed by software development team members and presented on the Jira Dashboard.They are: create a card, edit a card, find and move a card.These tasks are commonly performed by users on the intention to keep the tool and, consequently, team members updated on the activities carried out.

Stage 1: Analysis of Metalinguistic Signs
The metalinguistic signs in this inspection are evident in icons and the description of fields for a better understanding the action to be performed they are presented in all test scenarios, as show in Figures 6, 7, 8, 9, and 10.

Step 1. Interaction without the screen reader
During the creation and editing step of a new card, some metalinguistic signs are found, which guide the user on correct filling in the fields, in addition to containing information about mandatory filling.Figures 6 and 7 identify the metalinguistic signs presented in these steps, represented by symbols M1 to M8.For the action of locating and moving a card, no metalinguistic signs were identified.
In general, the evaluators understood the messages sent by metalinguistic signs.All signs were presented when viewing the screen, except those that appeared when hovering the mouse (tooltips) or clicking on static signs that did not have textual elements (Example: Figure 6 -[M1]).
In the card editing step, when interacting with the pencilshaped icon on the main board in an already created task, the sign [M9] was identified, which informs the user of the option to edit the card summary, as can be seen in Figure 7.The problems encountered are listed below: • The sign [M4], as it is not entirely in another language, uses a word in English (status) that may impair the user's understanding.It is worth mentioning that this word in English is used uniformly throughout the system, and its translation (situation) does not appear elsewhere inspected.• In sign [M8], it was observed that the description of the "flagged" field is in English, however, the language of the website and the researchers' domain is Portuguese, highlighting a translation failure into the language used.

Step 2. Mediated interaction with screen reader
On the main Jira screen, P3 found the create button (Figure 7 -[E1]), and when he clicked on it, he was taken to the functionality to create a new card.When entering the card, the field read was the summary field, in which the screen reader indicated that the text area was empty and, therefore, P3 inserted a text to follow in creating the card.P3 continued filling in the other fields, managing to complete the task of creating a new card, even though only some metalinguistic signs were identified by the screen reader (Figure 6 -[M3] and [M6]).It was also noticed that some fields were read in English, causing strangeness and difficulty to understand.Although the screen reader omitted practically all metalinguistic signs, P3 was also able to perform the task of editing a card changing the summary and description data, in addition to being able to include a comment.None of the signs that guide completion for better use of the tool were read by the screen reader, except for [M10] (Figure 8), which was read, however, in English.
To perform the actions of locating and moving a card, no metalinguistic signs were presented or used.To complete this task, P3 found and entered the card, which was expanded as a popup, where he located in the list a menu described as "Dot Action Menu" [D2], used to enter the list of the card's action options, as shown in Figure 9.The problems encountered are listed below: • On the new card creation screen, the sign [M8] is read in English.

• When editing a card, the signs [M11] [M12] [M13]
[M15] are not read by the screen reader, and the sign [M10] is read in English.

Step 3. Metamessage contrast
From the analysis of metalinguistic signs, it was noted that the system provides several guidelines to users regarding the description of fields for filling in information for creating or editing a card.However, it was observed that, for users with screen readers, this information is not accessed due to accessibility issues.Although P3 completed the tasks without significant difficulties, the system's communicability was compromised, as access to field labels needed to be equal for users with and without screen readers.
Furthermore, it was observed that the system displayed field descriptions in English mixed with Portuguese, which made it difficult to understand the information being provided to both user profiles, regardless they were using screen readers or not.It was also noticed the lack of feedback when editing the card fields, creating uncertainty about whether the task was completed successfully, as well as the need to edit only one field at a time.
A positive point highlighted by P3 was the correct labeling of the buttons when opening the card.However, the vast majority of metalinguistic signs were not recognized by the screen reader.Furthermore, P1 and P2 also wondered whether the card had been moved, as the change event is limited only to the card state selection button, and the system does not present any audio feedback to the user.

Stage 2: Analysis of Static Signs
When analyzing the system interface, it was observed that most of the Static signs are presented to the user in textual format, communicating the available functionalities and information necessary to execute actions in the system, as seen in figures 7, 10, and 11.

Step 1. Interaction without the screen reader
While executing the card creation step, P1 and P2 chose a button with the "+" icon within the card's column that could indicate the performance of this action.However, this option only allows the creation of the card summary.Then, they observed the entire main Dashboard and located the static sign represented by the button named "Create" (Figure 7 -[E1]), present in the top bar of the interface.When clicking this button, the system presents a new screen containing all the fields necessary to create the new card, as shown in Figure 10.
Still at this step, when filling in all the necessary fields and clicking the "create" button (Figure 10 -[E13]), the pop-up closed, and a notification was displayed indicating that the action was completed successfully, informing the ID of the card.Although P1 and P2 defined where the card should be created (e.g. in the Ideas or Missions in Progress column), after its creation, it was not easily found, making it necessary to navigate through the main dashboard again to see the card from the ID provided on the screen.
To edit a card, P1 and P2 navigated the system's main screen and clicked on the desired card.Thus, the system presented a dialog box containing information regarding the selected card.
In the upper right corner of the dialog box, a card summary information box is displayed, which can be hidden by the user.In the upper right corner, the card's action icons, such as Restriction, Sharing, Monitoring, and the option to close the card.
Thus, P1 and P2 edited the card information without significant obstacles, understanding the available functionalities and accomplishing the task to their objective.The problems encountered are listed below: • When interacting with the dialog above box, a potential problem related to the communicability of the system was identified: it is a field called "marked" whose function or action is not explicit to the user, causing inaccu-racy in its completion.• When acting on creating a new card, there is a potential problem related to the lack of clarity in the metamessage issued by the designer through the icons present in the dialog box: it is not transparent to users the functionality performed by the sign [E11] responsible for resizing the size of the card.

Step 2. Mediated interaction with screen reader
During the execution of the card creation step with the screen reader, P3 navigated through the top bar of the system interface until he found the button titled "Create" (Figure 7 -[E1]. However, with just this information, he was not left with its apparent purpose, highlighting a break in the metamessage sent by the designer to the user.When interacting with the button and navigating through the dialog box, the screen reading tool did not inform the user to read the "Responsible" and "Attachment" fields ([E13] and [E15] in Figure 10).Furthermore, when continuing to interact with the areas presented, the user is informed of messages entirely in English or mixing words in Portuguese and English, such as: "option não atribuído focused responsável" , "flagged", and "impediment" ([E16] in Figure 10), which raised doubts about the functionality of this field.Thus, once again, the communicability of the system was directly affected for people with visual impairments.
In finding and moving a card, P3 interacted with the selected card and located the "actions" button.When clicking this button, a list of tasks to be performed was displayed on the interface, including the "Move" option (See Figure 9).However, this specific option was not recognized by the screen reader.The problems encountered are listed below: • The title of the description field (Figure 10 -[E6]) was not read, and P3 was redirected to the toolbar below the field title, making it challenging to locate.), which has its title in English and presents the text "impediment" as an option for selection, also in English.

Step 3. Metamessage contrast
When analyzing the metamessages obtained from the use of static signs present in the interaction with and without the screen reader, it was possible to observe that, in both scenarios, there were problems related to the communicability of the system, where the information presented was not consistent with the user's default language, causing complexity in understanding the data.However, when it comes specifically to navigation carried out by P3, the user demonstrated incredible difficulty filling out the information necessary to create a card compared to users who do not use a screen reader.It is because several signs were not identified through assistive technology, and due to the lack of audio feedback, P3 could edit more than one field in the same interaction.

Stage 3: Analysis of Dynamic Signs
Dynamic signs are related to actions based on the user's interaction with the system to perform a task, as shown in Figures 7, 9 and 12.

Step 1. Interaction without the screen reader
In the scenario of creating a card, the dynamic sign was identified, and the event was listed with the title "flagged", which gave the option to select an item in English called "impediment" [D1], as shown in Figure 7.
To edit a card, in the main frame (Figure 7), when P1 and P2 hover the mouse over the card, a metalinguistic sign (Fig- ) is displayed with the name of the summary and a pencil icon appears (Figure 7 [D1]), next to the outline with a link, indicating that it is possible to edit the card summary.
When moving a card without a screen reader, P1 and P2 performed the task initially by moving the card with the mouse, clicking and dragging to the desired column, caused by implicit content in the task to be performed.However, P1 and P2 looked for an alternative way to carry out the test and, in this case, they returned the card to the initial column and clicked on the card menu (Figure 9 [D3]), displayed when hovering the mouse in the upper right corner of the card.Among the options listed, the first indicated "Move to" (Figure 12 [D4]) with an arrow in the right direction.When following the mouse by hand, the message displayed was "bottom of the column" (Figure 12 [D5]), which frustrated P1 and P2's expectations of moving the card to another column, thus ending the test unsuccessfully.

Step 2. Mediated interaction with screen reader
In the scenario of locating and moving a card, after P3 entered the actions menu (Figure 9 -[D3]), a list was displayed with the options to be performed, including the sub-list with the title "workflow", followed by the options in the existing columns to move the card.

Step 3. Metamessage contrast
When contrasting the metamessage emitted through dynamic signs, it was observed that Jira offers multiple options to action, such as moving a card.Although P3 completed this action, navigation through the screen reader presented additional challenges, requiring a sequence of steps to be performed in comparison to the interaction of P1 and P2, who performed the activity of moving the card using the mouse to drag it to the desired column.The other scenarios related to dynamic signs did not present problems in their use.As far as tests with a screen reader are concerned, dynamic signs did not generate significant problems, except for the lack of clarity in the titles of the sub-lists in the action menu for moving the card.

Stage 4: Metamessage Contrast
The researchers found several breaches when conducting inspections with and without the screen reader.In all test scenarios with screen readers, it was pointed out by P3 that experience with other screen readers was essential to explore the inspected tool and try to find ways to understand how it works with NVDA and understand how it behaves, what the most significant obstacles encountered and how the screen reader's behavior may be different about other tools previously used by P3, as well as the use of another screen reader.

Metamessage without a screen reader
During the creation of a card, P1 and P2 indicated that the "create" button was too generic, which resulted in doubts about starting the test.Then, in editing a card, P1, and P2 had no significant difficulties identifying the signs, consequently not generating communication disruptions with the tool.In the task of locating and moving a card, P1 and P2 were still determining whether the card had been moved or not, as the change event is limited only to the card state selection button.
From the contrast of the metamessage issued by the designer to the user, it was possible to observe that a large part of the metalinguistic signs are presented in the context tooltip format, providing help on how to interact with the system's functionalities.When it comes to static signs, content was predominant in text format.Finally, dynamic signs are arranged in icons that encompass a set of actions that can be performed on a card or that change behavior depending on the situation on the card.

Metamessage with a screen reader
In creating a card, the difficulties encountered were related to the field labeling order, which makes it challenging to understand the function, and when this field is a selection field, Figure 12.Navigation from the unnamed button (image with three dots) on the card shown in the main frame labels and field titles in English condensed with Portuguese were noted, making it difficult to comprehend P3 when using the screen reader.It was also observed that selection fields do not return feedback from NVDA, so P3 needed to understand whether his action had been executed correctly.
Still inspecting how to create a card, P3 demonstrated ease in finding the card creation and description fields, fundamental points for this scenario.P3 can also navigate between screens using the arrow keys and the tab without impediment, as well as carry out the task of creating a card in the respective scenario.However, the navigation went out of order, and P3 had difficulty locating himself on the screen again.
When editing a card, P3 indicated that the most significant difficulty was understanding how the tool organizes the items in the interface, as ordering is essential to turn navigation accessible through the screen reader.The order of the cards is also crucial during interaction with the tool, as P3 can have a clearer perception of how to identify which card and its description.Commonly, identifiers are located in the foreground of an item; however, in the tool, the identifier is located after the image description, which raised doubts in P3.It was also noticed the absence of feedback when editing the card fields, generating uncertainty to whether the task was carried out, as well as editing only one item at a time.It was observed that when editing an item, the screen reader did not remain in the same place, making it difficult for the user to locate it each time they completed an edit on the card.A positive point highlighted by P3 was the correct labeling of the buttons when opening the card.
P3 performed two tests to locate and move a card.The first was carried out partially successfully through an actions menu when opening the card.However, the listing title and the action after moving the card were not displayed by the screen reader.In the second test, P3 located an option in the list of activities called "Move", which had not been read in the first test by the screen reader.Following this option, he observed that the move scenario led to moving the card between Dashboards and not between columns, which was the original objective of the test.
Finally, based on the contrast of the metamessage emitted by the designer to the user, it was possible to observe that in the metalinguistic signs, some titles of the data entry fields were in English and, in some cases, the interface resources had labels identified by the screen reader, being absent for others.Furthermore, in static signs, the prevalence of resources in the English language was also observed.In dynamic signs, card management actions were grouped into a menu of options, which the screen reader did not predict.

Stage 5: Final Assessments
According to the results obtained in the inspections carried out, with and without the screen reader, communicability and accessibility problems can be observed in the evaluated tool.P3 highlights that Jira was not developed to meet the criteria of those who use screen readers, making it difficult to be independent in successfully carrying out tasks that may require the assistance of a sighted person.
With this, the researchers listed the problems related to communicability, indicating divergence in navigation and location by user P3, when compared to P1 and P2, regarding the organization of the columns with their respective cards, inferring the user's navigation.Furthermore, the absence of metalinguistic signs that can be executed by screen readers, as in the case of labels and filling instructions, generates disruptions in the understanding and interaction with data entry interfaces by visually impaired users.
Problems related to accessibility consists on the translation of fields reproduced by screen readers, cases that are evident in the user's navigation between screens and functionalities.In general, the tool presented several accessibility problems.
It can soon be seen that its use was not designed and thought of for a person who uses a screen reader, requiring a lot of effort to learn how to use the tool, as well as the need for constant help/support from a sighted colleague who, to solve the problems or impasses that may occur when using the tool.The time spent by a person with visual impairment on Jira or other tools that have this kind of accessibility issues is much greater, which directly and proportionally impacts productivity, when compared to a not visual impaired user.
Therefore, applying this inspection was essential to understand and highlight the barriers that a person developing software with visual impairment experiences in their daily lives when carrying out tasks mediated by screen readers in interactive and collaborative systems that are not accessible.

Inspection Discussion
When comparing the assessment of communicability of this study with the Carvalho [2021] study, it was noticed that there is a similarity of some access barriers that people can face with visual impairments in task management systems, such as Trello and Jira.These ruptures are based on inspections carried out by the researchers of both studies, when they highlighted the absence of labels for some essential fields and also the translation issue, where the signs should be in Portuguese and were presented in English.
From the analysis of these results, the need to improve task management tools for the inclusion of people with disabilities was highlighted.Therefore, the inaccessibility of resources in Jira, Trello, or other tools affects the interaction of these people during their professional journeys, especially in the remote environment.

Discussion and Contributions
We followed the actions presented in the inspection list of the Jira Interaction.However, it is essential to highlight that the blind inspector and researcher, P3, had the autonomy to make changes in interaction order, if necessary.The inspection was realized with headphones for help P3 focus.Moreover, before the interaction, P3 made some changes in NVDA to better the application experience.
P3 highlighted the importance of knowing the interpretation of some resources presented in English to realize the interaction correctly.We observe that using words in different languages of the operational system, like English or terms not specified, can create interaction barriers and be challenging to comprehend.It happened because the linguistic factors were not considered when constructing Jira, as for example, the use of words commonly used by users.
We also noted warnings about which the NVDA had not reported them.It means that changes in the system's state were not captured or indicated by assistive technology, creating a barrier to the understanding of the information and challenges for users' tasks completion.For example, the lack of system warning when commenting on the task card.P3 was not informed if the comment was saved or if the card had changed to a new column.
P3 made an important observation by noting the lack of labels on the system's data entry resources.The absence of identification in the text field, for example, made it challenging to insert the right information, which creates barriers to the proper use of Jira.Finally, it is important to highlight that P3 is experienced in using interactive systems.This scenario was essential to identify that his knowledge about using general and task management systems with screen readers provided alternatives to face interaction challenges.During the interactions, he independently searched for solutions to understand the barriers and create hypotheses about a specific usage problem.From there, P3 applied search parameters to validate his ideas and, thus, overcome obstacles to accessing information and communication.However, for users with less experience or beginners, this can generate a high cognitive load and partial or total disruptions in access to task management systems, affecting access and communication.
Given the problems found at Jira and observing the promotion of collaboration tools in development teams with the hybrid or remote work model, nine design considerations are proposed to improve accessibility to screen reader users.These design considerations are presented below, together with some evidence collected by the researchers: 1. Metalinguistic signs must be accessed by the screen reader.Evidence: some explanatory texts were not detected by the screen reader, especially headings and subheadings, making it difficult to fully understand the fields on screen.2. Provide feedback through the screen reader after completed actions.Evidence: Jira doesn't alert the screen reader after a task status update, causing doubts if the task was completed or not.3. It is necessary to display signs in the language preferred by the user.Evidence: some labels were displayed in English, which can be difficult to understand for Portuguese-speaking users.4. Provide an accessible keyboard option to move the cards within columns.Evidence: moving cards between columns while interacting with the screen reader proved to be a challenging task as the keyboard option needs a lot of navigation to be reached.P3 pointed out the complexity involved in performing this action, which is usually done by dragging the card with a mouse in the absence of a screen reader.5. Prioritize the user's navigation when opening a popup window to accomplish a task.Evidence: after completing a brief task within the modal, P3 noticed that the navigation was lost, and it was impossible to access the navigation on the highlighted modal.6. Define the orientation of the Dashboard, where the columns with the cards are concentrated in a tabular orientation, so the user can navigate using the arrow keys for a better localization in the system.Evidence: during the inspection, P3 was redirected to columns far from where the test cards and columns were concentrated.This resulted in a more significant time expenditure than expected to locate on the main panel.7. The fields available in the interface must follow a hierarchy level to facilitate understanding of the information.Evidence: locating a card through its identification was challenging when interacting with screen reader because the search field was the penultimate feature of keyboard navigation.8. Use of UX Writing techniques to facilitate the description of texts in the system.Evidence: the descriptions of buttons, list items, action menus, and filling-in fields directly influence the performance of tasks due to the need for more clarity in the text.9. Voice User Interfaces (VUIs) can make it easier to search for tasks and navigate the system.Evidence: in some cases, the navigation mediated by the screen reader was lost, or the search for a label absent in the tool burdened the interaction.Voice search to perform tasks would be an alternative to enable quick and easy locating in the tool.

Final Remarks
This research investigated the challenges developers with visual or hearing impairments face in maintaining awareness in remote software development teams.It was done by comparing this reality with the perspectives of people developing without disabilities.The results were evaluated based on the 3C Model of remote collaboration and consolidated from different perspectives for each group researched.The intersection between the HCI and Collaborative Systems research areas, considering accessibility not only in the construction of technological products but also in the inclusion of professionals, highlights the contemporary and social differences of the work presented.
Considering the moment of consolidation of remote work, the main contribution of this research is to highlight the diverse experiences of Brazilian professionals with visual or hearing impairments in remote development teams.It is hoped that by better understanding their reality, it will be possible to provide more and better employment and inclusion opportunities.
From the inspection of Jira, the most recommended tool among respondents, with accessibility problems among people with visual impairments, we highlighted issues linked to the breakdown of accessibility and communication in its use, resulting in dependence on third parties to carry out tasks in software development teams.software.
Regarding the limitations of this study, the small sample size stands out, mainly of professionals with hearing impairment, and the lack of mention of tools with accessibility problems in the survey, which, however, reflects the proportional representation of the groups involved and the inspection of the collaboration tool, aimed at people with visual impairments.The difficulty of expressing the concept of consciousness in a questionnaire may also have influenced information collection.
In future work, we will investigate, through interviews, more details about the realities presented, characterizing looking for the aspects of remote collaboration that influence the inclusion of people with visual or hearing impairments in software development teams, as well as how tools with disruptions work accessibility aimed at people who are deaf or hard of hearing.
Reflecting on these issues in the software development process, in addition to solving them, contributes to a more equal working environment when considering the interaction characteristics of people with disabilities.Therefore, this commitment strengthens the principles of accessibility, autonomous access, and security to digital services and active participation in the job market.
The researchers thank the people who responded to the questionnaire, highlighting in the speech of participant P16 the importance of inclusion and accessibility among software development professionals: "(...) we are definitely treated as equals, professionals that we are, but above that, as people".We understand there is still a long way to go so that everyone can feel included and recognized as professionals and, above all, individuals.

Figure 2 .
Figure 2. Roles, seniority and characteristics of participants

Figure 3 .
Figure 3. Self-assessment on Perception of being updated and Tools Support

Figure 4 .
Figure 4. Difficulty keeping up to date with colleagues' activitiesand ceremonies being cited as essential means of achieving this objective.Likewise, inappropriate management approaches were cited by 10% of respondents in this group as challenges to updating activities in the remote environment, as illustrated in the following comment: "No difficulties, Dailys help in the communication process.What makes it difficult is the management and distribution of projects that do not consider the occupation and shares of the employee involved in the tasks".Regarding difficulties, the accessibility of tools was mentioned by both groups of people with disabilities, being mentioned more than once in each group.They highlighted the main characteristics of the assistive technologies they used: automatic caption generator (hearing impairment) and integration with screen reader (visual impairment).People with visual impairments named the tools Jira and MS Teams as poor examples of accessibility.In this group, participants mentioned the need to make several adaptations to carry out their activities: "Teams and Gmail on the web are great examples of lack of accessibility.We were only able to use it because we made several modifications (workarounds) to be able to follow" [the rate of use of participants without disabilities].Only people with hearing impairment reported communication difficulties, citing the quality of the subtitles generated and obstacles when there are many people in virtual meeting rooms or, in written communication, when they have to consume confusing and long-winded texts.Some aspects of social relationships listed as making it difficult to maintain the team's awareness regarding the activities carried out refer to insecurity towards colleagues and a lack of empathy or otherness.These situations were brought up by people with visual impairments, who were also the

Figure 5 .
Figure 5. Difficulties updating the team about their activities only ones who raised issues of technical knowledge limitations about the English language and the technology used by other team members.The difficulties most cited by people without disabilities in updating colleagues about the activities they are performing reflect issues intrinsic to the remote work format, such as lack of time and availability or engagement for interactions.They were also the only group that brought up the lack of personal contact with colleagues, also mentioning the closed cameras in video conferences: "the eye contact, some people do not like opening the cameras in meetings.".Finally, an open space was offered to report other difficulties or support encountered by participants in carrying out their activities remotely: I would like to express any other difficulties faced or important support points for your daily life within your work context.When asked to express other aspects of remote collaboration, respondents from all three groups cited new points of challenge and support in their daily lives.Table2presents the data brought by each group, where it is possible to see that people without disabilities bring problems already reported in the literature on remote work.It is important to highlight the perception of a visually impaired person regarding the inclusion of the professional in the team: "generally, people decide to leave the disabled programmer aside, always in the last plan.It sometimes leaves us stopped."Regarding the positive aspects, in this same group, the importance of receiving support from their team and company was mentioned through welcoming, empathy, and help in the use of tools that are not very accessible: "I would like to highlight the importance of team support itself, despite the tools or methods used.An empathetic team is even more important than the tools used.Team awareness is critical in this context, and the company where I work works hard on this".People with hearing impairment did not mention positive aspects, and people without disabilities mentioned communication in virtual meetings (especially the daily meetings), voice channels, and instant messaging positively.

Figure 6 .
Figure 6.Metalinguistic signs on the card creating screen

Figure 8 .
Figure 8. Metalinguistics signs on the card creating screen

Figure 10 .
Figure 10.Static signs on the card creating screen

Table 3 .
Awareness perspectives -people with hearing impairment

Table 4 .
Awareness perspectives -people with visual impairments

Table 5 .
Awareness perspectives -people without disabilities