July is
Disability Pride Month
. I want to use the occasion to speak about my perspective on accessibility in GNOME and what I think we should do.
For disabled people, computers are often even more important than for abled (non-disabled) people. Many areas of everyday life are currently only accessible via a computer for many disabled people. Still, accessibility is often an afterthought in software and hardware development.
GNOME is fortunate enough to have many disabled contributors in its community. We have contributors who are visually impaired, deaf, autistic, ADHD, or who live with migraines and other chronic conditions. While we have people that care about accessibility and work on improving it, the general state is far from ideal.
The reality of tech communities is that they are often ableist and elitist. Probably more so than the average population. If a user or contributor struggles with a tool, blame is shifted to a “skill issue,” if an interface is simplified to make it accessible to more people, it’s “
dumbed down
”. Assistive technologies are often developed by abled people, without involving and paying disabled people. This also leads to an attitude where contributors expect gratefulness from disabled people for providing them with the most basic needs. All these issues are also not absent from the GNOME community.
What We Already Do
The goal of this section isn’t to boast about GNOME’s accessibility efforts. I believe that accessibility is a fundamental right, and nothing any disabled person is obligated to praise contributors for. Instead, the goal is to capture where we stand, and give other projects ideas they can adopt. Equally, I would be very happy to learn how other FLOSS projects try to work towards better accessibility.
Our review criteria for Core and Circle apps require checking if keyboard navigation, screen reader support, large text, and high contrast mode work. We also require sufficient contrast in apps, which we usually use the
Contrast
app to check against the WCAG requirements. We have shown that we are able to enforce these requirements by delaying the inclusion or replacement of apps until accessibility issues were actually fixed. That’s also an improvement GNOME has seen over the last years, since originally, no quality criteria for apps existed.
Many of the accessibility aspects are automatically covered by using our toolkits GTK and libadwaita correctly. I witnessed that accessibility is often considered during initial design and implementation. However, we don’t have any guidelines or requirements in GNOME for the development of these libraries.
The GNOME Foundation funded work on screen reader support in GTK 4 in 2020 and 2021. In 2023 and 2024, accessibility was also one of the larger areas the
GNOME STF
project worked on. That means both the GNOME Foundation, and the STF organizers were willing to allocate money for accessibility, which is a good sign.
However, accessibility is so much more than screen reader support. I think that GNOME’s general design philosophy is very important to being more accessible to a broader audience. This includes the focus on simplicity with good defaults, trying to avoid the possibility of misconfiguring the system, and the attempt to distract less. Translations, while often overlooked as an accessibility aspect, are another huge factor that makes our software accessible to so many more people. This shows that accessibility is hardly a separate set of features. Instead, it has to be considered as part of every area in a project.
Among the more “traditional” accessibility tools within GNOME are the screen reader, high contrast, reduced motion, always show scrollbars, sound over-amplification, input adjustments, and magnification. But equally important are the “Dark Mode” and “Do Not Disturb” mode, which are not directly labeled as accessibility.
How We Can Improve
Disability Pride is about
being proud of who you are
. But, like Queer Pride, it is also about fundamentally changing the society in which we live. Hence, for this year’s Disability Pride, I am also thinking of what we can change within GNOME.
Create an Accessibility Team
Except for a dedicated
accessibility
chat room, there is currently very little coordination for accessibility within GNOME. My goal for this month is to establish a formal Accessibility Team. My initial ideas for the team are to prioritize voices of those with lived experience, instead of having others make decisions for us. Nothing about us without us. In more practical terms, the team should help to maintain and develop guidelines and review criteria that are especially relevant for accessibility. The team should also review larger changes in the GNOME project that affect accessibility. Ideally, we could provide and user testing on accessibility features directly from the people who rely on them.
In addition to guarding the accessibility aspects of the software we produce, the team should also advocate for accessibility in our events, workflows, and tooling.
If you are interested in contributing, please reach out via
#a11y
or in our
issue #1
. Let us know where and how you want to contribute.
Use This Month Yourself
If you are disabled, and you want to share your experience in FLOSS communities or have accessibility issues in GNOME or other FLOSS software, report the issues and/or post about them on social media under
#AccessibilityInFreeSoftware
.
If you are a contributor, see if you can tackle one of the roughly
450 open issues
that are labeled with “Accessibility” this month. Try to broaden your horizons by reading articles from disabled people you know less about, or follow them on a social media platform. Embrace accessibility as a fundamental human right, not something disabled people have to show gratefulness for. Try to reflect on your language. Don’t use
sanist
language like “sane defaults,” using “good defaults” does the job. Ask yourself if you want to keep words like “idiot” in your vocabulary, knowing that “idiocy” was the first category the Nazis used to
systematically kill people
.
But also, don’t be scared of disabled people. We want to and deserve to be part of the community like everyone else.
Happy Disability Pride Month! Let’s build a desktop that is accessible to as many people as possible.
This blog post represents my personal opinions and not those of any organization I work for.
