Accessibility

How is accessibility understood?

Accessibility, as we found out during the course of this research, has a great many interpretations that have evolved and grown over the terminology origins and purpose. Originally understood as ways to ensure people with physical impairments and disabilities could access the same services as able-bodied folks through legislation such as the Architectural barriers act of 1968 in the USA through to various global technology and digital accessibility acts into the 1980s and 1990’s, accessibility is now commonly understood as the ways in which services (online/digital and otherwise) are made accessible to people across the spectrum of physical and cognitive impairments and disabilities. This study, however, uncovered the nuances that people contributing to and building Science and Research OSS have when it comes to how accessibility is described and meant. In this section we’ll also cover the differences described by the designers in Science and Research OSS as well as offering our own perspectives.

Accessibility is understood as making the Science and Research OSS tool more readily and easily available and usable by scientists and researchers that cannot, or never will ‘be coders’ as well as those that have historically been locked out of OSS (marginalized identities).

This understanding of accessibility is commonly spoken about in reference to building interfaces and GUI so that the SROSS might be operated through interface clicks, button, typing and menus as opposed to much SROSS which is operated through the command line or the terminal through a series of functional code commands.

A core developer at a bioinformatic platform speaks to the kinds of users that they have that are not always coming into the project with a level of coding knowledge that could be advantageous for them.

“A lot of the folks who are using our software are not trained computer scientists, or even like trained data scientists, a lot of them are biologists, who have picked up some command line software skills or a little bit of Python skills. And so keeping records can be challenging.”

This supports and connects to a value that we discovered throughout the conversations about Science and Research that upholds the process and practice of visibility as connected to replicability and reproducibility in order for the SROSS to participate in peer review-like processes. Without the ability for other researchers across the specific research field and beyond to access, use, replicate and potentially modify then the SROSS does not meet criteria for others to reproduce the same results or processes and therefore has not kept within the academic/scientific process of peer review.

A core developer at a bioinformatic platform reinforces the importance of scientists and researchers being able to trace another scientist or researcher’s process back to replicate.

“Users should always be able to figure out exactly what they did, you know, or somebody else should be able to figure out what the user did.”

A data scientist working in a university lab working on tools to improve human health speaks to how they make sure that the code they write is accessible to as many people that could do good with the tools and code as possible.

“Because we have the entire data collection system, we are trying to make it available for other researchers and eventually to pediatricians…so all of the code that I write is released publicly along with as much data as we can release on the vulnerable subject as well. And within my field, there’s a lot of people that would use our system that aren’t computational scientists. So all the code that I write, I really try and make sure that it’s as accessible as possible for someone who might not have coding backgrounds.”

This same participant goes on to speak about the connected subject below, that many of our participants spoke to around open science and research being ‘for the common good’ and if it is not as accessible as possible, it is not leveraging the opportunities to do good in the world.

Another way that Science and Research understands and emphasizes accessibility as important is that by making SROSS tools more readily available and accessible to more scientists, researchers and potentially other audiences, they uphold open science and knowledge as a ‘public good’ where anyone might have the opportunity to contribute to a critical scientific discovery.

A topic that recurred in our conversations with projects was the fundamental reason why Science and Research exists, in order to advance and understand the universe around us and come to better understandings about it and it’s problems. This, through the creation and maintenance of OSS, is, in theory and possibility, made open and collaborative. Here is where accessibility intersects with the purposes of Science and Research, where the more accessible the open science, research and tools are, the more possibility there is for crucial findings to be discovered and replicated.

A developer for a bioinformatics platform states that “I think by making the methods open, we can just advance more quickly to address advanced science more quickly and address global problems more quickly.”

Here we can see the hopes for open science and research laid clearly and it is also here that we might infer that the more accessible those open methods are, the better the advancement will be.

The is underscored by a comment from a developer of a data format unification project where they describe their past as a scientist, now a developer and how they focus on making sure that the scientists and researchers can access the tools in ways in which are accessible to those users, in order to solve their scientific and research problems.

“I’m no longer a scientist…But I understand how their time is valuable and how hard it is for them to focus on their science. So my goal, as a former scientist, who does code now is to take the code out of the way, like, you don’t have to worry about this hurdle of learning, programming and learning how to solve your problem.”

Lastly, we cannot forget that science and research for the betterment of humankind and the environment does not exist without the financial and government structures that support and enable it. A designer who works across multiple astrophysics projects speaks to the factual reality that many of these science and research OSS project are publicly funded in some way, and have a responsibility to the public regardless of its immediate relevancy or clarity to the public

“We’re all publicly funded. So all the data needs to be accessible by anyone, but primarily by research scientists.”

The recognition here that yes, the priority is to other scientists and researchers, yet ultimately if the science, research and OSS are not able to be accessed and used by them, then it is less likely to be able to contribute to the public good, the advancement of scientific knowledge and understanding.

Like some other aspects of OSS culture, Science & Research OSS tends to share a view that accessibility also includes ‘free’ as in OSS is freely available to access if you have the means to and freedom to configure and modify, again if you have the means to.

This is not an aspect of accessibility known by people that have not embedded in the OSS cultural movements deeply and therefore designers did not mention this aspect of accessibility in our study and generally in our experience, designers only ‘design’ for OSS with this in mind once they have been included in these cultural conversations in OSS.

This is a complicated topic across all OSS. With opinions differing on what is the responsibility of the individual that wants to be part of the OSS and what is the responsibility of those that build and maintain the OSS to ensure what constitutes free beyond the descriptions of commonly used licenses. Often these commonly used licenses haven’t considered the explicit inclusion of people that may not have a certain educational basis in computer science, coding, literacy, english or that they have reliable, safe and stable access to the internet and suitable hardware. Social constraints also apply in terms of time a person has to contribute if they have met the knowledge, infrastructure and tangible device requirements. OSS often values a certain level of proficiency and dedication to OSS.

An open source community manager supporting multiple open science projects speaks on the expectations that project may have when it comes to people that manage to meet the implicit barriers to contribution to an OSS project

“Accessibility is true if you’re saying people have the opportunity to use it. But accessibility is not being achieved if the goal is to ultimately increase the number of people who can use it at a level of proficiency that sort of meets their a prior expectations”

Another developer and maintainer at a Python based project for sounds based data speaks about how they feel like certain labs are getting attention from paper publishers because of their implicit access to tools and infrastructure and that there are people in labs in other countries doing amazing work without tool and infrastructure access yet they are unable to achieve a level of recognition. They speak to how this has informed how they build their tool with this kind of accessibility in mind.

“OS and [their specific OSS tool] lowers the barrier of entry for labs that may not have access to infrastructure tools”

This way of building tools describes accessibility in terms of equitable access and begins to demonstrate the complexity that the term ‘accessibility’ (and later usability) has within the Science and Research OSS field. This complexity pushes at a tension within OSS at large about diversity, inclusion and ethics in open source which is largely uncovered by official open source licenses yet is a critical and polarizing topic in OSS. From a designers perspective, we could lean on some common industry belief that the more diverse and inclusive the users involved in the process of configuring and building tools, the more accessible they become to those marginalized populations. This might then facilitate new context to scientific and research discoveries.

Designers in Science and Research OSS understand and apply accessibility in a different way that could be described as aligned with industry understanding of accessibility as inclusion of people using assistive technology as well as peoples differing levels of understanding, knowledge or context upon encountering a tool.

A designer at a lab that works across multiple Python related projects speaks to their frustration that the tools are unusable by assistive technology users.

“So…accessibility makes me really mad that our software is so inaccessible because it’s also used in so many fields. I’ve met too many people who have said, I just can’t work in this field. Because you know, I use this assistive tech, it won’t work with it, I can’t do the job.”

This person is advocating for the explicit inclusion of a user that could very well contribute critical findings or code to the SROSS or the next scientific or research breakthrough in their field yet they are fundamentally excluded from using the OSS and are required to find workarounds for their assistive technology or not use that tool.

Designers often speak of accessibility and user inclusion as designing simplicity and access for the most complex of user needs. You’ll often make that tool or service accessible or easier for others. A common and popular architecture infrastructure example is that when pavement curbs were lowered for wheelchair users they were also then used by those with other wheeled devices such as pushchairs, bicycles and wheeled zimmer frames as well as those that cannot step up or down easily. Making the city accessible to more citizens and improving their quality or life and their participation in society.

Another key consideration for designers is what legislation or government guidelines need to be adhered to when designing and creating open source, digital public goods tools. These legislations, like many funders and institutions encouraging or stipulating that SROSS be open source, are ensuring the accessibility of these tools beyond their immediate use, into the distant future where they may be accessed again after the creator and maintainers are no longer contactable.

A designer in a university based lab that works across multiple OSS projects details how this legislation ensured that accessibility was considered in the design phase.

“Legislation for accessibility in the public sector helped. So we had to talk about it to make more people aware. So it became an integral part of the design. Personally, I’m really glad it happened. And the more inclusive and the more accessible, the better.”

The same designer goes on to speak about a somewhat unique case for SROSS where an output of the research was to be presented to the public through a museum exhibition. Here the designer describes how the complicated and contextual information needed to be accessible to the public, who likely have varied levels of knowledge about that context yet still, many levels of interest, knowledge, age and understanding needed to be considered.

“[a project] was specific to linguists and historic historical analysis of that, but then it was presented in a museum so it needed access to the general public. So these are two almost opposite ways of presenting. Counting it because you have a completely different language. You have different conventions of recognising elements. So you have to cater for both.”

Conclusion

We can clearly see in the insights about accessibility that it is a diverse term that cannot be used to express a single meaning or application in Science and Research open source software. However, we can also clearly see that the ways in which Science and Research understand accessibility ultimately contributes improvements to the term in better expressing what it means to be accessible, inclusive in the science and research fields at large.

We see can see the spectrum of designers, developers and the roles and functions in between doing the difficult work in sharing their understanding of the term and accessibility in practice for the good of broad user types (from the designers) and for the betterment of science, research and open tooling (from the developers and other OSS roles)

Here we see evidence of a Designer working across many Python related OSS projects to be inclusive and collaborative in their approach to accessibility. Creating a space where non-designers are informed and work together to make accessibility improvements to an interface in real-time and show that it is not always a process that is laborious.

“[What] I have managed to do with the accessibility space is create contributing event workshops, where you come, I’m going to teach you an accessibility concept, you’re going to practice it on our code base, and we’re gonna clean it up and contribute it, as a group.“

There are many more positive stories about integrating accessibility into SROSS project we discovered through the research and these project set a great example for projects that may believe, as covered in chapters around the perceptions of design and prioritization, that making a SROSS tool accessible, means to ‘rehaul’ ‘refactor’ and undertake a huge time investment into development.

Here a lead developer on a collaborative ethnography platform speaks to how they’ve prioritized mobile-first ways of using the tool.

“One main priority = accessibility. Have a friend working on accessibility for [their OSS project], who helped a lot in that area to bring ideas and things and they’re now putting it into the code. Since the beginning, [we] designed in a mobile-first approach, which helped a bit with accessibility. But it’s not something you’d be [typically] doing on your phone because it’s too much text to read, pdfs to add, etc. There are usability issues on the list to improve on mobile especially. Then it’s not only about rendering the content but about screen readers and how they’ll read the content, and how people can see the colors, etc. Have a lot to improve re: accessibility”

This speaks to an honest assessment of accessibility where mobile might not be the common way these tools are used and most project may think in similar terms that there is too much information, data and processes for their OSS tools to be effective on mobiles, however, for a user that only has access to a mobile, or limited access to powerful lab computers or can only use mobile internet this option presents opportunities for their research that is worth making happen.