So @gnome is removing the x11 session, leaving just the Wayland one.
If this goes out before Orca, the GNOME screen reader, is fixed to work on Wayland, it will mean that people who rely on screen readers will have no way to use one on GNOME. And thus on the major Linux distributions.
So I’m hoping the plan is that this change will not land until GNOME has a working screen reader.
#accessibility #a11y #gnome #linux #openSource #foss #wayland #x11 #orca https://peoplemaking.games/@ailepet/112077559713299711
@aral GNOME folks are well aware of the problems with Orca on Wayland, and actively working to fix them. There's even funding for this work, thanks to the Sovereign Tech Fund. I'm personally working on a new Wayland-native accessibility stack that aims to eventually replace AT-SPI and support sandboxed apps, but there are also efforts to fix problems in the existing stack in the short term. cc @sonny
@aral@mastodon.ar.al @matt@toot.cafe @sonny@floss.social Well, I don't know if you've read that MR, but it's targeting GNOME 48, which leaves plenty of time to fix the accessibility issues.
@aral@mastodon.ar.al @matt@toot.cafe @sonny@floss.social It's the default because it's already quite functional, except for the problems you point out. Additionally, if you increase the number of users on Wayland, it is easier to identify problems and fix them. If it weren't the default, who even knows how long it would have taken us to identify that there were problems with Orca
@nah @matt @sonny If the GNOME folks didn’t realise that Orca was broken before making Wayland the default that’s even worse. It would mean no one on the GNOME team is testing accessibility. If they knew and made it the default anyway, it just shows that accessibility is seen as not essential. So I’m actually not sure which is worse. And we can’t go back in time so hopefully lessons will be learned and this will remedied as soon as possible.
@aral@mastodon.ar.al @matt@toot.cafe @sonny@floss.social Ok, but I remind you that GNOME is not a company, it is a project created by a lot of volunteers. Everyone works on what they want/can, the idea is precisely that there are people who test Wayland and come to help and fix the problems
I think we all agree that accessibility is important, and we all want to create software that is inclusive enough for everyone... but we must also come down to reality, where as long as the problem can be worked around, a lot of ppl think that nothing needs to be fixed
Removing the possibility of workarounding and shoving problems in your face is a strategy to attract volunteers to help improve the software
Finally: public appeals where bad faith is assumed and the project is criticized as if it were a company with a team of full-time developers is a strategy to reduce people's motivation to work on things. You don't need to shit on GNOME for things to be fixed, but on the contrary, the strategy is to show up with proposals and willingness to improve the situation
@nah @aral @sonny @matt Accessibility is a human right. Drastic regressions to the accessibility of a system that disabled users rely on are a human right violation.
We can cut a lot of slack to volunteer contributors, but not “human right violations are permissible” amounts of slack.
Ultimately, it’s the responsibility of the project’s leadership (volunteer or not) to set norms like “we can only accept your contributions if they’re accessible”.
@nah @aral @sonny @matt As a norm, that’s not particularly new in open-source. I’ve contributed to several projects who only accept contributions that 1) align with project goals, 2) pass peer review and 3) pass multiple test suites.
That can definitely be a barrier to contribution. But there are also smaller hobbyist-focused toy projects with lax norms that people can contribute to, if strict norms are a deal-breaker.
@fvsch@hachyderm.io @aral@mastodon.ar.al @sonny@floss.social @matt@toot.cafe Privacy and security are equally important; however, people's solution here is for us to continue using X11 by default until the alternative is "perfect" and we can switch to it.
The change to Wayland is huge, and requires many improvements across multiple projects (many of which don't even belong to GNOME as such), so it's not exactly trivial. We need more people working on this, and therefore we need to raise the interest of potential contributors to iron out all the remaining rough edges.
As I said in a previous post: until Ubuntu put Wayland by default, many people were not even willing to work with Wayland. It's important to understand this: the world of free software moves by motivation. If you're a software user, and you have a problem with said software that you can work around... how much motivation do you have to improve said software? You'll probably continue working around the problem until you can't do it anymore, and only then you'll contribute to solving the problem once and for all.
Right now, the workaround is to continue in X11, even despite the security and privacy problems that this implies. Many people don't realize how insecure X11 is, and they minimize these problems. GNOME is aware of this, and made Wayland the default several versions ago, also because Wayland was already usable for many users. X11 was still available as a fallback in case Wayland wasn't ready for you yet.
The proposal now is to eliminate X11 once and for all, and to do so a goal has been set: GNOME 48 (which will not be released until March 2025). Blocking issues for this also began to be collected, the current state of Orca being one of them (see Sonny's post), and this has been 4 months now.
I must highlight that accessibility is a fundamental pillar within the development of GNOME, we seek to create a desktop that can be usable and accessible by everyone, without discrimination. However, I must also highlight that there are many more aspects to take into account in order to achieve this. It's not as simple as it seems to be, and at GNOME we always seek to achieve the best solution. Assuming bad faith and criticizing the project as openly as Aral does is not productive. Perhaps putting pressure will work in contexts such as governments or companies, but not in free software.
@nah @fvsch @sonny @matt No one is assuming bad faith on the part of the volunteers. The pressure is for the corporations who profit from GNOME. Take GNOME away tomorrow and what does Red Hat do? What does IBM do? What does Canonical do? They have millions. Can they afford to make GNOME accessible? Yes. Should they be ashamed it doesn’t have a working screen reader? Also yes.
@aral@mastodon.ar.al @fvsch@hachyderm.io @sonny@floss.social @matt@toot.cafe
No one is assuming bad faith on the part of the volunteers. The pressure is for the corporations who profit from GNOME.When you talk about GNOME, you're talking about the entire project and all its contributors, not just the companies that benefit from it. Keep that in mind: public attacks can reduce the motivation of contributors (as has happened many times before)
@nah @fvsch @sonny @matt I’m going to leave it at this: If I ran a large corporation that benefited from GNOME but didn’t want to support it financially or pay for it to be accessible, etc., I’d want any criticism of it to be seen as criticism of the poor, unpaid volunteers. It’s a great way for corporations to avoid criticism.
@aral@mastodon.ar.al @fvsch@hachyderm.io @sonny@floss.social @matt@toot.cafe And I'll put it this way: if I work on a free software project for the benefit of the entire community, without earning anything from it, purely in my free time... and then someone decides to post criticizing the project from above to down about problems that I know and that both I and colleagues on the same project try to solve, without even helping... I really don't think it feels good to me.
I understand your point, but you also understand mine. If you want to attack companies, mention them directly, or criticize their products (for example, Ubuntu or RHEL). Attacking GNOME is useless in that case.
@nah @aral @sonny @matt I am personally extremely critical of this framing of the GNOME Project as having no responsibility and no accountability, on the basis of most of the work being done by volunteers. This does not fly for other NGOs, and should not be used as an argument here.
Maybe time for the GNOME Foundation board and team to step up and set some clear norms and expectations for digital accessibility, if they have not done so until now?
I'm not sure why we keep arguing, I already explained that usable screen reader is a hard requirement for dropping the x11 session.
With that said I agree and we are working on it. The GNOME Foundation will need the means to its ambition so I hope we can count on your support then.
@sonny @nah @aral @matt It’s great to have your word that it’s a blocker, but that’s not correctly reflected in the MR you linked to (https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/98#note_1907233).
- The MR's metadata does not show it as blocked by another issue or MR, as far as I can tell?
- The comment you linked to says “potential blocker”, and the only response says it’s acceptable as a blocker *provided someone else commits to doing the work*. That is *not* a “hard requirement”, and probably requires an update.
@sonny @nah @aral @matt There’s another discussion in this thread that is not limited to this specific case, about what kind of expectations of accessibility people can have from an open-source project with a majority of volunteer contributions. I think it’s an important discussion, with some contrasting views.
@fvsch
Not possible, AFAIK. You're looking for metadata where there can be none.
GitLab does not have a "mark a merge request as a blocker of another one" feature, especially not across different projects, and _especially_ not in the Community Edition. It doesn't even let you mark issue tickets as blockers of another in the Community Edition ️ https://docs.gitlab.com/ee/user/project/issues/related_issues.html#blocking-issues
@nekohayo Good to know. In that case, maybe that merge request should be moved to a draft status:
> If a merge request isn’t ready to merge, you can block it from merging until you mark it as ready.
That’s a bit of a mixed signal, because it can mean “not ready for internal reasons” or “not ready for external reasons”, but better than nothing. But better than no signal.