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.

Week 25

This week's icon is for Val Packett 's project:
Demostage : "Perform live demos from a virtual desktop"

Check out all weekly app icons created so far over here and follow my icon creation adventures as they happen (including sketches) on the Fediverse .

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source . Funded by community sponsors (every little helps!).

I couldn't remember something for weeks. It popped into my head during a run — a relief, even though the memory itself was not pleasant. This episode of my flaky mind reminded me of this movie.

I won't give you even a hint of what the movie is about. The strength of it is not the premise, but the mood, the superb acting and Christian Bale's physical dedication to the role impressed me, alongside a cast of wonderfully weird characters and ominous presence of giant spinning machines. If you somehow missed the movie, give it a go. It's one of those that keep coming back to you.

• Up early, packed variously, bid 'bye to M&D, and the American Meeks.
• Into Cambridge for H's baptism at Christ Church; with B&C&C, Mary Rogers and several of H's friends. A lovely service & dunking - out to Browns for lunch together.
• Bid 'bye to N., dropped M & J & Sade to the station to help move M. into her new London home.
• Dropped Mary home, slugged a bit, prepped music for and ran the evening service - Charlee spoke well. Relaxed.

Week 24

This week's icon is for Jiří Eischmann 's project:
Meshy : "Meshcore mesh network client"

Check out all weekly app icons created so far over here and follow my icon creation adventures as they happen (including sketches) on the Fediverse .

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source . Funded by community sponsors (every little helps!).

Update on what happened across the GNOME project in the week from June 26 to July 3.

Third Party Projects

Haydn Trowell says

The latest version of Typesetter updates the built-in Typst compiler to version 0.15, which brings a long-awaited feature: variable font support – no more warnings and faulty font rendering when using your system’s default fonts. This release also adds a popularly requested feature to the editor: manual font size adjustment – use the standard keyboard shortcuts to make the text larger and smaller.

Get it on Flathub: https://flathub.org/apps/net.trowell.typesetter

albfan reports

Finally is here: gitg 50, more stable and customizable

Full of new actions to interact with your git repos, even customizable ones

Once downstream packaging is available, give it a try and send feedback

Shell Extensions

Fabiano Junior says

Hello everyone! I’ve just released new updates for ChromaLeon , my extension that extracts and applies colors from your wallpaper to your GNOME Shell and LibAdwaita theme.

The focus of these updates was refinement: the color extraction system is now smarter, ensuring better compliance with WCAG accessibility guidelines regarding contrast. Additionally, I’ve improved the icon generation system (folders and apps) to make it much faster and more efficient, now generating icons almost instantly.

You can check out the project on GitHub and GNOME Extensions .

storageb reports

Create custom time-of-day schedules for the Night Light!

Night Light Scheduler lets you create a custom schedule for GNOME’s built-in Night Light allowing you to automatically adjust the color temperature throughout the day according to your schedule.

Features:

• Create a schedule to automatically adjust Night Light color temperature throughout the day
• Smoothly transition between temperatures with an adjustable transition time
• Import and export schedule configuration as an editable .ini file
• Uses GNOME’s built-in Night Light functionality
• Easy to use visual interface

More information is available on the project’s GitHub page .

Miscellaneous

Cleo Menezes Jr. | World Cup mode 🇧🇷🇧🇷 says

Mosaic WM is maturing and being refined, polishing the rough edges, finding bugs, hearing from you.

To do that, I’ve created a Matrix room and I’d like you to be there. You don’t need to be an expert, just someone who wants to help make it better.

In?

Damned Lies ↗

The internal application to manage localization of GNOME & friends modules

Guillaume Bernard announces

This week, we released for Damned Lies a new feature for team coordinators. When updating your team details, you can now create a presentation that will be sent to new team members as a notification. Use it to present the team, the workflow, link your docs, identify a module for newcomers…

Internships

AnonymouX47 announces

Five weeks into GSoC 2026, I’ve made solid progress on GPU reset recovery in Mutter!

When a GPU reset occurs, Mutter currently has no way to recover; the desktop either freezes or crashes. My project implements a recovery path: detecting the reset, waiting for it to complete, recreating the context, and propagating that change through the compositor to recreate resources so rendering can resume.

The display now comes back after a reset, and the session remains usable, though there’s still work ahead: notably, automatic framebuffer recreation and fixing the desktop background, which currently renders with garbled textures after recovery.

Read the full details, including a demo: https://blogs.gnome.org/anonymoux47/2026/07/02/gpu-reset-recovery-in-mutter-a-progress-update

That’s all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

Over the past few weeks, I have been writing the backend for the vocabulary-puzzle generator for Crosswords.

But what entirely dictates a valid word placement whilst being mindful of all edge cases and managing the state of the puzzle upon the exploration of possible solutions?

Finding valid intersections

For each word in the list, the vocab generator searches for every valid location where the word at the current depth could be added (or not added) to the current puzzle. A candidate must satisfy several constraints:

• Word must intersect existing puzzle.
• Intersecting characters must match.
• Existing letters must not be overwritten by conflicting letters.
• The word is within a 30×30 board boundary.
• Puzzle remains entirely connected.
• Word placements cannot connect flush to their head/tail to another word.
• Could there be multiple valid intersections?

As more words are added, the number of possible intersections rapidly grow. A single placement may produce several valid connections, each of which must be evaluated independently.

Modeling the intersections

The vocab grid generator represents candidate placements by using the coordinates of the intersection, placement direction (across, down), and the offset of the intersecting character within the word. As a whole, an intersection can transform the entire puzzle. For instance, “APPLE” and “PEAR” are just two words, but share four possible intersections. Rather than selecting one immediately, we ultimately want to record every valid candidate.

Each of these shared candidates then become a potential node in our recursive search tree. As our puzzle grows in size, the problem becomes less about placing words and more about exploring all valid intersections whilst preserving the integrity of the puzzle state as we add and rearrange words.

As is the case for many people working in the security industry, the last few months of my life have been focused on dealing with people wanting to use LLMs everywhere. From an enterprise security perspective that’s not an inherent problem - what’s more of a problem is that people want those agents to have access to resources like their calendar and email and so on, and now we have somewhat non-deterministic agents that seem very enthusiastic to achieve what you asked whether that’s a good idea or not, and we’re combining this with credentials that give them access to sensitive data, and leaving those credentials on disk where they can be committed into git repos or exfiltrated to some other service to make use of them on the agent’s behalf or well just any other number of things, at which point your CEO’s email is suddenly readable by everyone and you’re having a bad day.

As I mentioned in my last post , pretty much every strong mechanism for keeping credentials in place is just not supported in the wider world. We can imagine a universe where agents use hardware (or at least hypervisor) backed certificates to obtain credentials and any that end up leaking are worthless as a result. But, sadly, that’s not an option for most people using existing identity providers. The state of the art is that you use the device code flow and a human authenticates and the token ends up back inside the agent environment and then it proceeds to do whatever it wants with it and you just hope that you wake up the next morning without an awful infoleak occurring.

(An aside: I do not like the device code flow as used in enterprise environments, and I never will. The identity provider doesn’t have a real opportuity to inspect the security posture of the system asking for the token, and as a result some identity providers will restrict tokens that are issued in this way. The common alternative of doing stuff using a more standard flow and having a redirect URI pointing at localhost works fine for local systems and is a pain for remote ones, even if you can commit crimes with SSH forwarding. I’m going to suggest something that I think is better, and you are free to disagree)

I’m not in a position to get every identity provider and service provider to change their security posture, so I’m somewhat stuck in terms of the tokens they’re willing to issue me - largely either JWTs or opaque access tokens, with no support for any mechanism of binding that token to an instance. The token that’s going to have to be provided to the remote service is something I have little influence over. But that doesn’t mean I can’t influence the token that lands inside the agent’s environment. I can issue a placeholder token to the agent, and force it to communicate via a proxy that swaps out the placeholder for the real thing. The worst the agent can do is exfiltrate the placeholder token, and as long as malicious actors don’t have access to that proxy, it doesn’t matter - nobody else can do anything with the placeholder.

This isn’t a terribly novel insight, and it seems like almost everybody has reinvented this on their own. But a lot of these implementations involve you somehow obtaining the real token in advance and then pasting that into something that generates a placeholder that you provide to your agent environment somehow, and it’s all a bit clunky and awkward, and it also means that you need to deal with something that keeps track of the mapping between placeholders and real tokens and oh no we’ve just invented a secret store, and if you want this to work at scale and reliably you’re just invented a high availability distributed secret store, and a lot of people who’ve read that are now shaking their heads and reaching for gin. Can we simplify this, and improve security at the same time? I think we can!

Remember when I said “as long as malicious actors don’t have access to that proxy, it doesn’t matter”? What if they do? What if they compromise one machine inside your environment and are then able to email a bunch of employees and convince their agents to send more tokens back to them and then delete the email before a human reads it? Now you have someone inside the wall with access to those tokens, and presumably with access to the proxy, and now they can be anyone whose agent was gullible enough to think sending them a token was a good idea. This isn’t good!

So, I thought for a while, and I came up with a new idea. We can have a broker service that obtains credentials for us. We can run that centrally, away from the agents. A client in an agentic environment can request a token, and that can result in a URL being generated and the user being directed to open a URL in a browser and authenticate. When the user authenticates, the authentication flow redirects the confirmation back via the broker, and the broker obtains the real auth token. The obvious thing to do now would be to return the auth token to the client in the agentic environment, but we don’t do that. Instead, we mint a new JWT, and add a new claim - one that contains an encrypted copy of the token. In the process we can copy over all the original claims, because those aren’t secret - and now even if the client inspects the token to figure out what access it has, it’ll get a correct answer. We sign the new token with our own signing key, and pass that back to the client. The client now has a legitimate JWT that is utterly useless, because the signature isn’t trusted by anyone other than us.

How does it use it? It makes an API request via a proxy, including the new token in the Authorization: header. The proxy verifies the signature on the token, and then decrypts the original token and swaps out the fake token for the real one. The remote API sees what it expects, and everyone is happy. There’s never a real token in the agentic environment, but also we don’t need to store anyting anywhere. The only state is the encryption keys, and those can be injected into the environment at startup. You need to scale? Just start more of these processes. You need to support multiple availability zones? Just start more of these processes in different places. No persistent data is ever held in the broker or the proxy. You don’t need to care about distributed databases or secret stores.

This felt wonderfully elegant and I felt smug about coming up with a better idea, and then I went to a bar earlier this week and sat down to read RFC 8705 and the guy next to me saw that over my shoulder and asked what I was reading and I explained why I was interested and we talked about agentic identity and then he mentioned that fly.io had something that sounded very similar and I read that and gosh yes it is very similar, so damn you fly.io for stealing my ideas 3 years before I even had them. Anyway. Now I need to do better.

Remember that there’s still a risk around anyone who has access to the proxy having access to the encrypted keys? We can remove that risk as well. It’s not uncommon for agentic environments to have an identity issued via something like SPIFFE , at which point they have a client certificate. You can probably guess where I’m going with this. If we require that an agent present a client cert to the broker when requesting a token, we can embed a representation of that client cert into the token we mint. The proxy can then require mTLS for the client connection, and can verify that the presented certificate matches the one represented in the token. If it does then whoever’s using the token has access to the private key associated with the environment it was issued to. If we then ensure that the private keys backing these certificates are either hardware or hypervisor backed, and as such tied to a specific instance, we now have a high degree of confidence that the token can only be used in its intended environment. Even if our identity provider doesn’t support RFC 8705, we can.

This is fairly straightforward where you’re using a platform where your identity provider is also the environment that’s consuming your tokens, and more annoying for third parties. The broker potentially needs some amount of third party vendor knowledge to make that work for everyone. This is even more the case where login isn’t via your identity provider (thanks, github), but none of this is insurmountable - just annoying. And where vendors issue opaque tokens rather than JWTs, this still isn’t a problem; we can just mint a new JWT that includes the opaque token as an encrypted claim, and include the same certificate binding. The opaque token ends up being the thing that’s presented to the third party, but only after we’ve verified the mTLS binding.

In an ideal world none of this would be necessary - someone would spin up a new agentic environment, a user would prove their identity, and a certificate embodying that identity would be issued to the environment with a private key that can’t be exfiltrated. That certificate would be sufficient to obtain new certificates associated with the same private key, and we could still bind that into mTLS identity. This would be much simpler, but browsers don’t support it, so it’s not likely to happen any time soon.

Anyway. Even if we can’t have the best thing, we can do better than we are at the moment, and also it would be lovely if we could standardise on this rather than have everyone build their own thing. The end.