Fedora Strategy 2028: Focus area review (Accessibility)

We’re working on Fedora Strategy 2028 — our next five-year plan. We are now reviewing those Objectives and their associated Impact. Read this guide for details on the current planning phase.

Focus Area: Accessibility

By “Accessibility”, we mean digital accessibility (commonly abbreviated “a11y”). This means designing and providing software that it is usable by people with disabilities.

This came up very early in our planning discussions as a top community priority. We believe that improvements in this area will directly increase our user and contributor base. And, this links right to the heart of the Fedora vision, which calls for community-built free and open source software to benefit everyone.

We developed three Objectives that form a funnel: reaching potential people who might be interested in Fedora, making it possible for more people to use Fedora Linux, and making it possible for those people to contribute and become part of our community.

Objectives & Impact

Objective Impact
Fedora websites and docs use the current best-practices for a11y. Expanded access to information allows people we were not able to reach before to enter the Fedora world.
Fedora Linux Editions use the best-available open source a11y tech People who benefit from assistive technology can become Fedora Linux users.
Our project tooling follows best a11y practices. Users who benefit from assistive technology can become Fedora Project contributors.

The work at hand:

For each Objective (what we plan to accomplish) and Impact (why we are doing that) our goal is to validate these things:

  1. If the Impact is achieved, it’s reasonable to expect an increase in active Fedora contributors.
  2. Success in the Objective logically results in the intended Impact.
  3. That link is reasonably sufficient — that is, it represents everything needed to have the Impact.
  4. While there might be other ways to have similar Impact, the chosen Objective is the right one for Fedora right now.
  5. The wording is precise and clear. The Objective is concrete, and the Impact is (at least a little bit) inspirational. Together, they fit into this Focus Area.

For many of the other focus areas, I plan to make four separate topic posts: one for the focus area in general, and one for each specific Objective. In this case, the three Objectives fit together closely enough that I think one will be sufficient. (If that turns out to be wrong, I’ll split it up!)

As outlined in the roadmap, this post will close in one month. So, let’s get started!

1 Like

I think that this focus area is really good, but my mind goes to two questions. First, how will we educate ourselves on accessibility best practices? Second, how will we incorporate accessibility solutions that already exist in the Linux ecosystem?

It can be easy to make assumptions on what specific things do or do not need attention for accessibility. We can also easily come up with the wrong solutions that become a hindrance to people with accessibility needs, or even fix things that aren’t broken. Figuring out how we will learn is important. I think we knew that already, but it bears mentioning.

For the point about being a platform for accessibility solutions, I would love to see some kind of process or pipeline for the community to submit software that tackles these problems. We want people to know that they can bring their applications to Fedora and will be supported. We should also think about how to reach out and collaborate with developers who we want to work with who may otherwise not be prioritizing Fedora. In some respects I imagine this isn’t too different from how we manage packages now, but in this case I feel like we might have to hunt for the solutions. We really want people to know that we want software for an accessible ecosystem, and we may have to reach out to devs to sell them on collaborating with us. I’ll leave it there because really I’m outside of my wheelhouse right now, lol.

The reason I’ve been thinking about point 2 a lot is because I came across what looks like a great voice input application called Numen for navigating in the system. It seems to work great! The developer also made a desktop environment that works great with it called Tiles. I got so excited when I found this because we have this focus in Fedora right now, but I don’t know what to do with this knowledge except share it. I passed it to the DEI Team, but I don’t think we’ve done much with it since. Using Numen as an example, do we know what we’re supposed to do when we find software that we want to see in Fedora for this purpose? It would suck for a developer to be excited to collaborate with Fedora but then lose interest because we didn’t have a process or system to capture that interest.

Last thing: maybe it’s just me, but I think having an accessibility focused Fedora spin could be cool. Don’t know if that’s even something that would interest folks, but it feels like it could be. Like something with Tiles and Numen working out of the box, for instance.


I am not sure how a11y friendly is for each of Fedora Editions/Spins/Remix or even command line only environment currently.

May be in 5 years, all final products of Fedora will be a11y ready.

If the short term aim is to offer users an option, will it be helpful if all a11y efforts are focused - for example, create an a11y spin that implements a11y feature one by one.

After an feature is considered ready, then other end product can pick it up and integrate it.


There is an accessibility working group as part of the dei-team. There’s also a Red Hat team who are working on this and who have reached out to us. I agree that education needs to be a key part of this.

In some ways (as you note) this is implicit because it’s how we do most things. I think the process of doing this outreach and connection falls under Activities, linked to an Output along the lines of “best upstream tooling integrated in the OS” — or even better, “we have a process for bringing the best upstream a11y tools into the OS”.


Hello folks! I am Divya & I’m brand new here. I found this thread interesting & wanted to leave a suggestion since I think it’s relevant. The CHAOSS project has some metrics like Documentation Accessibility, New Contributors etc, that we could leverage to determine what success looks like for each Objective i.e. how much of an Impact does it actually have?

Also, I think it 'd be cool to get project & software accessibility added to these metrics eventually, once we have a demonstration of how it works.


this is Vojtech, I am part of small Linux a11y group composed of Redhatters. I am blind and I am a Fedora user.

I definitely welcome this proposal, it looks good to me.

I must say that I am focusing mainly on the second point. Some suggestions (in context of blind users):

  • if you want to gain new Fedora users, I think you are aiming at two distinct groups:

    • already existing Linux users - there are users of various mainstream Linux distros (Arch linux, Ubuntu) or some custom-made Linux distros based on mainstream ones (Accessible coconut, Talking Arch). If you want to attract those users, it might be interesting to find limitations of their current distros and fix them in Fedora. And advertise it - most of those users are concentrated on the Orca screenreader mailing list, which is currently orca@freelists.org. There are a few more lists, let me know if you are interested and I will find them.

    • users of other computer OSes - the key point here is to identify gaps in Fedora accessibility, which are showstoppers for users of Windows and Mac. these users are already used to some standard - some things just ARE accessible and if they don’t are, they just do not consider even trying Fedora at all. There are particular cases - we can have separate conversation about that.

  • I am not sure if I understand the third point: what tooling are you talking about? Wiki, Gitlab? fedpkg? copr? Discourse? By the way, all interfaces I have just mentioned are already highly accessible.

  • I must say that Fedora already ships quite wide array of accessibility related software. However, it still needs some non-trivial actions to get it all playing nicely together. This is something what distracts the second group of users mentioned above. I am working on a Fedora remix called Vojtux (GitHub - vojtapolasek/vojtux: Scripts and documentation about accessible version of Fedora). Maybe this is something worth discussing - and possibly turning it from hobby project to something what can be eventually fully integrated into Fedora.

  • with regards to education on desktop accessibility… this is quite complicated because there are no suitable materials concerning Linux desktops. There are either very high level materials which talk about accessibillity such as section 508, or there are very low level materials pertaining to particular graphical toolkit or library (GTK, QT)… but no materials for general developers. We are also trying to find some solution within our group.


Hello. I am another visually impaired member of the mentioned Red Hat a11y group.
I agree with everything what @vpolasek said. Something, which I don’t know how to accomplish, but might at least not disappoint some prospective visually impaired users, would be having some more natural speech synthesis voices, as some users might be quite picky about that aspect. And yes, for troubleshooting some text console screen reader would be helpful as well.


Yes, plus Koji, Bodhi, fedpkg, our git forge, bug tracker, etc. I’m glad to hear that many of our tools already have good accessibility. Part of including this objective is to make sure we keep moving forward on this.

Ever since I attended your presentation on Vojtux, my goal has been for us to get to a place where you don’t need to make it because our core deliverables are accessible. A lot of this work will have to involve us working with upstream projects to incorporate accessible design at the outset, but I think we can do it. I know we must try.


Devin Prater on Mastodon shared how he has felt the increased interest in accessibility, specifically through sighted developers being interested in Orca. They also mentioned the Orca mailing list so I decided to share here as well.


@vpolasek, I would be interested in any of the mailing lists or forums you frequent around this topic. Could be a good spring board for those of us who know too little about accessibility.

Question for the Council - is this thread something we would like to advertise in these accessibility spaces to get more input and ideas from people who are more familiar?

I’d say yes, but I would also note that this thread closes in 10 days. But we can continue to drive conversations around accessibility in dei-team with the Accessibility Working Group folks.

Linux, as a whole, has a great base for building accessibility. In particular, BRLTTY and LibLouis are even used in proprietary screen readers. Cups, with the cups-filters package, allows printing to Braille printers, called Embossers, with no need of installing a printer driver. Unlike just about every other Braille translation software for Windows or Mac, Cups can use ImageMagick to allow for embossing images. Nothing else that’s even close to free allows for that.

However, most distributions of Linux don’t use these tools well. Orca, the screen reader for the GUI, needs programs to talk to to it through ATSPI. To get most of these programs to work, environment variables need to be set. These are the ones I know about:

export GTK_MODULES=gail:atk-bridge

I had to google for like 10 minutes to find this, and I know what to look for. New Linux users won’t know that they need to look for this, or turn on the assistive technologies checkbox in Mate’s personalization settings.

As far as desktop environments, Mate is still the most accessible, even though its Gnome 2 roots are showing as accessibility decays. In particular, if you quit a QT or Chrome-based app, the window manager just puts focus in the middle of nowhere, so you have to spawn an Orca window for focus to be set back in order. KDE is focusing on accessibility, so that’ll be nice when it’s ready. I don’t know about Gnome, since last time when I asked for help, they said that unless I can code, I pretty much can’t. So I left them.

Something that will need to be solved as this grows is that accessibility developers are very few. The maintainer of Orca doesn’t even do that as her job, she does that in their spare time. A new screen reader being developed, Odilia is made up of maybe 3 people.

Another part of attracting blind people to Fedora is all the nice apps we have on Windows. There’s one called Tweesecake which is a sort of HUD where we can interact with Mastodon, Home Assistant, Github, and a few more things, without even needing a window open. This works by grabbing keyboard commands and speaking output through the screen reader. When I asked if a version for Linux could be made, one developer said that it probably isn’t possible to make something like it for Linux. Wayland should allow for non-visual interfaces.

Games are another issue, but one person has worked on Audio game manager, which brings a lot, but not all, Windows games to Linux through Wine. This is one person, maybe a second person on the side. I’ve heard that, a long time ago, TuxType was accessible with a command line flag, but I’m not sure how up-to-date that still is.

As for me, I’m an intermediate user with little patience these days. I can install Fedora, as I’ve done many times over the years. I can put the export variable “cheat codes” into my .profile file, and enable assistive technologies support. I added steps for that in a quick docs thing some months ago. I am willing to help, and test. But I am not willing to be the only one that does this. If I write documentation, there should be people to help.

My motivations are simple. I want to be in a community where I can point out an issue, possible reasons why, with debug files and logs, and get feedback as they’re fixed, when they’re fixed, and have those fixes in an update pretty soon, not six months or a year after they’re implemented. I want to be able to make my computer work the way I want, not how proprietary companies say I should use it. And my boss uses Linux, happily. He can just install any distribution of Linux he wants, and just… use it. No need to enter cheatcodes into a .profile, no need to know how to use the screen reader before you even begin the installation, and he can even use a touch screen, so mobile Linux is open to him.

So, we already have a pretty good base to build on. But Gnome 2 (Mate) is crumbling in accessibility, and KDE seems to be the only desktop environment focusing on accessibility as a goal right now. I hope that as a non-developer, I can be of some use to Fedora as it tries to clean up this 17 year old mess.


Yes, sometimes, setting things up is a challenge, however, things are improving.
The QT environment variables are definitely not needed for QT 6, and likely 5. Same can be said about GTK_MODULES, which are not needed at least from GTK 3. GNOME_ACCESSIBILITY, when researching it, is also something from the GNOME 2 days or might be earlier. And ACCESSIBILITY_ENABLED will not be needed for Chromium a11y, but yes, this one might stick a while longer, because of all the Electron apps.

That’s the kind of things which I wish I’d known before. We’ve been holding on to all these environment variables. So all I need now is:

export accessibility-enabled = 1

Let’s take those kind of specific functionality questions over to Ask Fedora and focus on the … focus area, please. :classic_smiley:

Thanks for coming over and proving your input!


Hey there,

I’ve learned about this topic on Mastodon. This is my first post on this Discourse instance.

I’m a sighted user and interested in accessibility. Since the mentioned documentation is sparse, my knowledge is on the domain of accessibility of websites and apps, but I believe, some insights are transferable.

I am excited to see such a big distro as Fedora taking accessibility seriously.

Now, there is an Orca mailing list surprised. I’m confused about the location, though. Back on the Mailman Welcome to Gnome discourse screen reader users - Accessibility - GNOME Discourse was named as new home of the mailing list, but when in doubt follow the experts there. Note that the mailing list above is also listed on Projects/Orca - GNOME Wiki!

So what could be good first steps to educate you on desktop accessibility?
Well, I could imagine that reaching out to Joanmarie Diggs ( https://www.igalia.com/team/jdiggs ), maintainer of Orca, would be helpful. Perhaps you can reach an agreement with Igalia to have her getting paid as a consulting gig for you?

Marco Zehe is also a known name in the blind community. If you have people understanding German give them a listen to „Barriefreiheit mit Marco” podcast, where he explains how to operate JAWS on Windows. This can give you a glimpse on what most people are experienced with using (JAWS and NVDA are predominant).

On the web I can use the builtin screenreaders on mobile systems (TalkBack on Android, VoiceOver on iOS).


We have seen Numen mentioned above. I want to take the opportunity to raise the awareness that accessibility is more than just for the blind (although they play an important role!).

is a quick overview about the different groups that are on the mind when someone talks about accessibility in general. The great thing is that once you design with accessibility in mind an even larger group benefits! (On the web I highlight the use of subtitles for example. Not only deaf people are using them but also people in noisy environments such as on commute).

From my quick dabble with Qt, Tkinter and that like I learned that „roles” and „accessible labels” are important. On the web, you are getting a long way when you can navigate and use an UI with the keyboard alone. Focus was mentioned above. That describes the area „under the cursor” which can be read out. Accessible labels are used for speech navigation, for example.

Another important aspect is colour contrast. Here you might need to work with the creatives that develop the various themes that can be used in the different Desktop Environments.

Pay attention when using the abbreviation a11y.
Through #AudioEye Will Get You Sued — Adrian Roselli I learned that it is a registered trademark. Consult legal when in doubt.

I want to close for now with a link to GitHub - kdeldycke/awesome-falsehood: 😱 Falsehoods Programmers Believe in which can help with learning about false believes (e.g. that every person has a first and a last name).

I wish you all the best with the execution of this strategy!


@ryuno-ki Thank you for joining the conversation here and sharing this feedback! :raised_hands:


3 posts were split to a new topic: Links to #dei broke

This topic was automatically closed after 25 days. New replies are no longer allowed.