Contributing to an Open-Source Screen Reader

Overview

Screen readers are software tools that read aloud what is on a computer screen, allowing users to interact with the computer without relying on visuals. The primary users of screen readers are blind and visually impaired people, but they can also benefit other users, such as those with dyslexia or learning disabilities.

However, good screen readers are not available for all computer systems. The most popular screen readers are VoiceOver for Mac and JAWS and NVDA for Windows. While some Linux systems come pre-installed with an open-source screen reader called Orca, it has many limitations. Searching for first-person accounts from BVI Linux users, I found several Reddit posts describing the lack of accessibility features. Here are some examples:

A screenshot of a Reddit post, which reads "I would basically rate support for the visually impaired Linux a C. There are some good aspects, but also many bad aspects (BTW you can only use Orca on a select few desktop environments without hitting bad bugs)..."

A screenshot of a Reddit post, which reads "Given all of these, I can't go with linux when it comes time to build my own pc. It's simpyly not viable, unless I want to run a headless server, with ssh. It also means I can't recommend it to my blind friends, so they'll be stuck either using windows of Mac for a daily driver, just like me."

These accounts illustrate the common problems with Orca and Linux as a whole: they are difficult to install, buggy, and lack necessary features.

Odilia is another open-source screen reader for Linux with some distinct advantages over Orca. Firstly, it does not rely on a particular desktop environment. Secondly, it has fewer dependencies than Orca, making it easier to install. The only other dependency is a Linux text-to-speech program called Speech Dispatcher.

Despite these advantages, Odilia has not seen the widespread adoption that Orca has because it is much earlier in its development. The project has only existed for a few years and is still in Beta, meaning it is not ready for everyday use yet. For my project, I contributed to Odilia’s development to help speed up the development process and implement features that make Odilia more easy to use.

Positive Disability Principles

Here I go discuss how the positive disibility principles relate to my work.

Is it ableist?

This project aims to create a screen read reader, which is already a popular tool for BVI users, and similar open-source projects, such as NVDA, have been received positively by the BVI community. Given this, I don’t believe this project is ableist.

What parts of the work are accessible and what are not (for example, are both design tools, and their outputs accessible)?

Being free and open source means that the Odilia source code is more accessible than some other screen readers, like VoiceOver and JAWS, and it’s free to sye. However, it is still in Beta, so it does not provide the rich feature that these other screen readers do. Additionally, the source code requires technical knowledge to understand. While the eventual goal is for Odilia to be usable for people with or without technical skills, it is not accessible to most users in its current state.

Are people with disabilities engaged in guiding this work? At what stages?

While my work on Odilia is focused on the needs of the BVI community, they are not the primary leaders. My decision to work on a screen reader was influenced by the first-person accounts of BVI users, so the did guide which project I chose to work on. I hoped that working on an open-source project would allow be to tackle issues brough up by the users. However, because Odilia is not complete, end-users are not really submitting bug reports yet. According to their bios on the project website, at least one of the project leaders is visually impaired, but I don’t want to make assumptions about the identities of the rest of the team.

Is it being used to give control and improve agency for people with disabilities?

I believe so. Screen readers can help BVI people be more independent by helping them use a computer without relying on others. Additionally, Linux is a popular operating system for developers, so helping to make Linux more accessible could lower the barrier of entry for BVI people wanting to develop new technologies.

Is it addressing the whole community (intersectionality, multiple disabled people, multiply disabled people)?

Unfortunately, this project primarily focuses on BVI people and may leave out some intersectional identities as a result. For example, because they are speech based, screen readers are inaccessible to Deafblind people. While braille support is mentioned on Odilia’s website and a skeleton for that module exists in the codebase, it does not appear to be fully implemented yet.

Accessibility of Open Source

Heron et al. provide a comprehensive overview of the benefits and drawbacks of open source accessibility projects. The authors point out that many open source projects begin to address the creators’ own needs, which may not be addressed by existing tools. Additionally, the large pool of contributors makes it more likely that a project will stay up-to-date, and the code being open to the public allows other developers to learn from open-source projects. However, they also point out that open-source projects often lack the resources to provide the same features as proprietary ones, and that they tend to provide little end-user documentation or technical support.

A11y

The A11y Project is an initiative dedicated to making technology more accessible. The project website provides resources for creating and auditing accessible websites. In addition, the word “a11y” is often used to refer to any accessible technology project, even if it is not directly tied to the A11y Project.

While my work is not directly connected to web accessibility, I think it is in line with the a11y movement’s goals. Two principles emphasized on the A11y Project’s website are Inclusion and Opportunity; the project aims to make technology more inclusive and to create more opportunities for disabled people to participate in online spaces. Similarly, screen readers create more opportunities for disabled people to engage with computing. This also allows disabled people to become technologists and create their own accessible software.

Odilia

Odilia is the screen reader that I have chosen to work on. It is written in Rust and aims to provide some unique features:

Orca

Orca is an open-source screen reader that is part of the GNOME desktop environment. It is primarily written in Python. As mentioned in my overview, Orca is not a perfect solution, but it is currently the most popular screen reader for Linux.

NVDA

NVDA is an open-source screen reader for Windows. Unlike other screen readers, this project is primarily lead by BVI developers. It also has significantly more features than most other open-source options, which has made it a viable competitor JAWs and VoiceOver. According to a WebAim survey from 2019, NVDA is now the most popular screen reader.

Because NVDA only works on Windows, it is not a direct competitor to Odilia. However Odilia includes many similar features to NVDA, such as support for addons.

Methods and Validation

Part 1: Choosing a Screen Reader

I had originally planned to contribute to Orca, but I was unable to do so because I couldn’t compile it on my computer. After cloning the Git repository and installing the necessary dependencies, I got the following error:

ERROR: Dependency lookup for atspi-2 with method 'pkgconfig' failed: Invalid version, need 'atspi-2' ['>= 2.50.0'] found '2.44.0'.

This was because I had an outdated version of atspi, a library that allows Linux to communicate with AT devices. However, my package manager said that I had the most up-to-date version and would not install the newest one. I asked several Linux forums but got no response, so I decided to switch to Odilia.

Odilia was much easier to install because it’s written in Rust. Rust’s compiler also acts as a package manager, so it was able to install all the necessary dependencies automatically.

Part 2: Compiling and Running Odilia

Although it compiled easily, I was not able to run Odilia on my first try. Running it produced this error:

Error: creating log file ‘/var/odilia/odilia.log’
	Caused by: no such file or directory (OS error 2)

This is because the /var directory in Linux is used primarily for system logs and is not writable on all distros. I found an earlier conversation in the dev team’s Discord about this, where they recommended editing the config file so that it would write the log file to a different location. I pointed out that this was not an ideal solution, and that it doesn’t make sense for the log to be in the /var directory anyway. One of the project leaders agreed and made a Git issue for it. Fixing this issue was the first contribution I made to the project.

Part 3: Fixing Log Issue

I started by reading through the code and documentation to figure out where the log file was being generated. Odilia uses an log_settings object to keep track of the default logging settings, so to change the file’s location, I just had to update the appropriate field in this object. However, this was not as simple as hard-coding a path name because I wanted to store the log in the user’s home directory, meaning the exact path would be different for every user. My initial attempt used the \$HOME environment variable, but the project leaders rejected this change and asked me to use \$XDG_STATE_HOME, which defines the default location for application state data. After making this change and fixing some formatting errors, my pull request was accepted.

Part 4: Attempting to Fix Speech Dispatcher

The second issue I worked on was fixing Odilia’s speech, though I haven’t been able to solve this yet. Odilia uses Speech Dispatcher, a text-to-speech library for Linux. Someone made an issue on Git because Odilia was not able to launch Speech Dispatcher itself. Running Odilia alone wouldn’t cause any sound to be produced, but running another program that uses Speech Dispatcher first would allow Odilia to use it. I don’t have this problem when running Odilia, so investigating the issue was difficult. I started by reading the available documentation on the relevant packages: Speech Dispatcher (text-to-speech), Tokio (a Rust runtime), and SSIP (a protocol for sending screen reader information between processes). I then compared how these are used in Odilia to the sample code provided in the documentation, but I couldn’t find any obvious differences. I also looked at spd-say, another program that uses Speech Dispatcher, and couldn’t find anything that this program does differently than Odilia. My plan is to try installing Odilia on different Linux distros to see if I can replicate this error anywhere.

Validation

I’m primarily using community feedback and the impact my changes have on Odilia to validate my work. The first issue was one that I brought up, and the project leader ended up making an issue for it, which indicates that the community agreed that it was a problem. While my first pull request was rejected, it was eventually accepted after I made some changes. Because of this, I would consider this fix a success. However, the second issue I looked into has not yet resulted in changes to the Odilia codebase. Since I still haven’t tracked down the source of the error, I have not made any changes to the code. Because this part of the project did not make an impact on Odilia, I would not consider this portion a success. Overall, I’m happy with the contributions I made, but I still wish I could have done more. Hopefully I can continue to have an impact on Odilia in future work.

Disability Model Analysis

This project is guided by three principles from Sins Invalid’s Ten Principles of Disability: leadership of those most impacted, cross-disability solidarity, and collective access. Additionally, one of my primary goals is to create something that aligns with the needs of disabled users in order to avoid making a disability dongle.

Leadership of Those Most Impacted

This principle states that disabled people, particularly those who hold other marginalized identities, should be the guiding force in accessibility work. This is in contrast to the traditional power hierarchy within academia, where “experts” are prioritized over those with lived experience. Allowing those most impacted to lead both gives more power to marginalized people and ensures that the work does not result in disability dongles.

Because I wanted my work to align with this principle, I chose my project based on first-person accounts from disabled people about what barriers prevented them from accessing computing. As mentioned in the overview, I found multiple accounts from BVI people talking about the lack of accessibility in Linux, so I chose to work on a tool that would make Linux more accessible. My initial plan was to contribute to Orca because that project already has a lot of interaction with BVI users. Odilia, on the other hand, is not at a stage where users are meaningfully contributing yet. While at least one of the leaders of the Odilia project is visually impaired, I don’t know if the other developers are. Because of this, I don’t think my work upholds this principle as much as I hoped it would.

Commitment to Cross-disability Solidarity

This principle emphasizes the importance of collaboration between people with different disabilities and access needs. Although disabled people are a diverse group with varying needs, we are all impacted by ableism, and solidarity between disabled people helps to amplify the voices of people who are most impacted by ableism.. In their article on the ten principles, Sins Invalid emphasizes the need to support “especially those who are most often left out of political conversations.”

While I have encountered barriers in computer science as a result of my health problems, I recognize that I come from a place of privilege as someone who is able to access a computer easily. Because of this, it was important to me to choose a project that makes interacting with computers more accessible. I wanted to make sure that my work didn’t just benefit me, but helped people with access needs that I haven’t experienced myself.

Collective Access

This principle is about “[sharing] responsibility for our access needs” as a community, ensuring that everyone’s access needs are met. In contrast with the medical model of disability, which places the burden on individuals to make things work for them, this principle emphasizes the community’s responsibility to make things accessible for others.

Contributing to an Odilia is in line with this principle, since the end product helps to make Linux more accessible to people who may not be able to access it otherwise. Additionally, both Linux and Odilia are free and open source, which makes them more accessible to people who cannot afford some of the other options.

Disability Dongles

The concept of a disability dongle was coined by Liz Jackson to describe accessibility technologies made by people who do not understand the intended users’ needs, resulting in products that are impractical or solve “problems” that did not need solving. In addition to using resources on products that don’t actually benefit disabled people, disability dongles also treat disability as a problem to be solved, rather than pushing for societal changes to make the world more accessible.

Because I am not blind or visually impaired, there’s a greater chance that my work would result in a a disability dongle. My hope was that allowing BVI users to guide the direction of my project would ensure that my work aligned with the needs of those users, but as previously mentioned, switching to Odilia meant that users were no longer determining what I worked on. However, screen readers are popular tools with a long history in the BVI community, so I think it’s unlikely that this is a disability dongle. Additionally, the fact that so many BVI people have complained about the lack of accessibility in Linux indicates that there is a need for a new solution like Odilia.

Learning and Future Work

Overall, I learned a lot from this project. As the first open-source project I’ve contributed to, working on Odilia taught me the process of making Git issues, submitting pull requests, making revisions based on feedback, and communicating with project leaders. On a technical level, I learned about Rust libraries that I wasn’t familiar with. My current research is In Rust, but that project is an operating system, so we aren’t using the standard libraries. As Rust grows in popularity, learning about all of its tools is very beneficial.

I also learned more about how screen readers work and how important they are to the BVI community. Reading through the source code and documentation for Odilia made it clear how complicated screen readers are, and how difficult it is to make them compatible with the UI for every program the user might want to use. It also illustrated how difficult it can be for non-expert users to install and run a screen reader on Linux. A lot of Linux software assumes that all users are tech-savvy and provide little instruction on how to run them. While this is ok for a project that’s still in development, I think this creates a massive barrier to BVI people who are just starting out with Linux. As a TA for UW’s systems courses, I’ve seen how Linux is a barrier to beginning computer science students, and the lack of an easy-to-use screen reader makes this even worse.

Moving forward, I plan to keep contributing to Odilia. I really enjoyed working on this project and interacting with the community, and I think the product could be useful to a lot of people once it is more complete. My plan is to first see if I can find more information about the Speech Dispatcher issue, but if not, I will move on to another one. In the future, I might also ask to update the user documentation to make it more understandable for non-technical users, but I decided not to do that until I have done more work on the project.

References

  1. (2022, January 14). State of funding accessibility on linux, perspective of a blind user. [Online forum post]. Reddit. https://www.reddit.com/r/linux/comments/s3vvot/state_of_accessibility_on_linux_perspective_of_a/

  2. The A11y Project.(n.d.). About. https://www.a11yproject.com/about/

  3. [ChipsAhoiMcCoy]. (2023, May 25). Linux and Scren Readers for the Blind. [Online forum post]. Reddit. https://www.reddit.com/r/linux/comments/13rym2j/linux_and_scren_readers_for_the_blind/

  4. GNOME. (n.d.). Orca Screen Reader. GNOME Library. https://help.gnome.org/users/orca/stable/index.html.en

  5. Heron, M., Hanson, V., & Ricketts, I. (2013). Open Source Accessibility: Advantages and Limitations. Journal of Interaction Science, 1(2). https://doi.org/10.1186/2194-0827-1-2

  6. [Jeremus_Ironflesh]. (2021, September 9). Any opinions on Orca? [Online forum post]. https://www.reddit.com/r/linux/comments/pl2r1t/any_opinions_on_orca/

  7. [HyperMisawa]. (2022, January 12). The state of funding accessibility for handicapped people on linux is quite dire. [Online forum post]. Reddit. https://old.reddit.com/r/linux/comments/s1twza/the_state_of_funding_accessibility_development/

  8. [nyakomon]. (2021, September 9). How is accessibility on Linux? [Online forum post]. https://www.reddit.com/r/linux/comments/duqfly/how_is_accessibility_on_linux/

  9. NV Access. (n.d.). About NVDA. https://www.nvaccess.org/about-nvda/

  10. Odilia. (n.d.). Odilia Screen Reader. https://odilia.app/

  11. Orca. (n.d.). Orca - A Free and Open Source Screen Reader. https://orca.gnome.org/

  12. Institute for Disability Research, Policy, and Practice. (n.d.). Screen Reader Use Survey. WebAIM. https://webaim.org/projects/screenreadersurvey8/