Having just read this, I'm saddened that this is still the state of alternative input devices on Linux.
-
Having just read this, I'm saddened that this is still the state of alternative input devices on Linux. And the use of the phrase "accessibility maximalism" is utterly depressing. Of course we should want maximum accessibility. https://nocoffei.com/?p=451
@fireborn thank you for sharing a link. I had never seen this blog or heard of Talon before, so this was incredibly informative.
-
@fireborn thank you for sharing a link. I had never seen this blog or heard of Talon before, so this was incredibly informative.
@leaferiksen I have also never seen this blog before. I had heard of Talon in passing, but had no idea that things were this bad.
-
Having just read this, I'm saddened that this is still the state of alternative input devices on Linux. And the use of the phrase "accessibility maximalism" is utterly depressing. Of course we should want maximum accessibility. https://nocoffei.com/?p=451
@fireborn@dragonscave.space that phrase quite literally was said in context of dumping huge wish lists on volunteers. This is what he said:
I don't feel like answering this point-by-point.
Accessibility-focused people tend to come with maximalist lists of demands ("We need to have all these very intrusive capabilities, or the system will not be accessible at all").
Practical day-to-day improvements on accessibility of Wayland desktops happens in the Accessibility room on the gnome matrix instance.
The work that is happening is on two tracks in parallel:- Maintenance on the aging and barely functional, 20 year old a11y infrastructure that was inherited from X11 based desktops (see e.g. https://blog.gtk.org/2024/03/08/accessibility-improvements-in-gtk-4-14/)
- Work on a new Wayland-first system that will be able to sit underneath a cross-desktop Accessibility library (AccessKit)
-
@fireborn@dragonscave.space that phrase quite literally was said in context of dumping huge wish lists on volunteers. This is what he said:
I don't feel like answering this point-by-point.
Accessibility-focused people tend to come with maximalist lists of demands ("We need to have all these very intrusive capabilities, or the system will not be accessible at all").
Practical day-to-day improvements on accessibility of Wayland desktops happens in the Accessibility room on the gnome matrix instance.
The work that is happening is on two tracks in parallel:- Maintenance on the aging and barely functional, 20 year old a11y infrastructure that was inherited from X11 based desktops (see e.g. https://blog.gtk.org/2024/03/08/accessibility-improvements-in-gtk-4-14/)
- Work on a new Wayland-first system that will be able to sit underneath a cross-desktop Accessibility library (AccessKit)
@tragivictoria The point of low level access being a necessity is true. There is not a single platform that does not have this, apart from maybe iOS. Linux, and especially Wayland, doesn't have the mass market adoption to be special. As demonstrated in multiple fields at this point, not supporting Wayland for low level tooling is often the more viable approach than putting in the effort.
-
Having just read this, I'm saddened that this is still the state of alternative input devices on Linux. And the use of the phrase "accessibility maximalism" is utterly depressing. Of course we should want maximum accessibility. https://nocoffei.com/?p=451
@fireborn To be clear though, the phrase "accessibility maximalism" was invented by the author of the post. What Matthias Clasen (a maintainer of both GTK and Mutter) actually said was:
> Accessibility-focused people tend to come with maximalist lists of demands ("We need to have all these very intrusive capabilities, or the system will not be accessible *at all*").
Accessibility should not be compromised, but security shouldn't be either. And these projects have very limited resources.
-
@fireborn To be clear though, the phrase "accessibility maximalism" was invented by the author of the post. What Matthias Clasen (a maintainer of both GTK and Mutter) actually said was:
> Accessibility-focused people tend to come with maximalist lists of demands ("We need to have all these very intrusive capabilities, or the system will not be accessible *at all*").
Accessibility should not be compromised, but security shouldn't be either. And these projects have very limited resources.
@fireborn So my reading of what he said is that we can't simply demand to have unrestricted, intrusive access to the whole desktop environment simply because that's how we (assistive technology developers, myself included on Windows) have always done it. We need to design new protocols that meet both accessibility and security requirements at once, without compromising either.
-
@fireborn To be clear though, the phrase "accessibility maximalism" was invented by the author of the post. What Matthias Clasen (a maintainer of both GTK and Mutter) actually said was:
> Accessibility-focused people tend to come with maximalist lists of demands ("We need to have all these very intrusive capabilities, or the system will not be accessible *at all*").
Accessibility should not be compromised, but security shouldn't be either. And these projects have very limited resources.
@matt I agree with that. I do also agree that low-level access makes accessibility easier, though dumping an entire page of fixes that are needed on volunteers when you have not bothered to triage how impactfu each fix is is its own kind of unhelpful.
-
@fireborn So my reading of what he said is that we can't simply demand to have unrestricted, intrusive access to the whole desktop environment simply because that's how we (assistive technology developers, myself included on Windows) have always done it. We need to design new protocols that meet both accessibility and security requirements at once, without compromising either.
@matt Again, like I said before, Linux, and whale and especially, don't have the mass market adoption to be special. This isn't just in the accessibility space. The effort required to get low-level tooling to work for a niche of a niche of a niche is simply too high.
-
Having just read this, I'm saddened that this is still the state of alternative input devices on Linux. And the use of the phrase "accessibility maximalism" is utterly depressing. Of course we should want maximum accessibility. https://nocoffei.com/?p=451
@fireborn honestly when i read it that phrase just made me angry
anyone who says such things shouldn't have any say when it comes to accessibility
-
@tragivictoria The point of low level access being a necessity is true. There is not a single platform that does not have this, apart from maybe iOS. Linux, and especially Wayland, doesn't have the mass market adoption to be special. As demonstrated in multiple fields at this point, not supporting Wayland for low level tooling is often the more viable approach than putting in the effort.
@fireborn@dragonscave.space i have no idea what this refers to in my post
-
@fireborn@dragonscave.space i have no idea what this refers to in my post
@tragivictoria I was referencing the need for "intrusive capabilities." I agree that we shouldn't just contiguously hound volunteers for changes without any regard for impact or ongoingwork. Like I've always said, we should celebrate progress.
-
@tragivictoria I was referencing the need for "intrusive capabilities." I agree that we shouldn't just contiguously hound volunteers for changes without any regard for impact or ongoingwork. Like I've always said, we should celebrate progress.
@fireborn@dragonscave.space ah, i see, 100% agreed then.
-
Having just read this, I'm saddened that this is still the state of alternative input devices on Linux. And the use of the phrase "accessibility maximalism" is utterly depressing. Of course we should want maximum accessibility. https://nocoffei.com/?p=451
@fireborn Oh. Oh no.
I used Talon for a bit a few years ago when I was having shoulder problems. It's an incredible empowering technology, a fundamentally new and different way of interacting with your computing. It's also fundamentally built on the premise of scripted low-level control of the entire system UI. This is what makes it so empowering; there are no limits to how it can be extended.
Wayland is fundamentally designed to prevent such automated control. This is probably irreconcilable.
-
@fireborn Oh. Oh no.
I used Talon for a bit a few years ago when I was having shoulder problems. It's an incredible empowering technology, a fundamentally new and different way of interacting with your computing. It's also fundamentally built on the premise of scripted low-level control of the entire system UI. This is what makes it so empowering; there are no limits to how it can be extended.
Wayland is fundamentally designed to prevent such automated control. This is probably irreconcilable.
@SpindleyQ In the places where it is a problem that can be solved, it's made more complex by the fact it is compositor specific
-
@SpindleyQ In the places where it is a problem that can be solved, it's made more complex by the fact it is compositor specific
@fireborn yeah, I feel like the Wayland mindset is "these things are the compositor's responsibility, any exceptions need to go through a limited protocol and have their use cases thoroughly vetted to prevent abuse"
And the Talon mindset is "the user knows their accessibility needs better than me, so I will give them complete, straightforward programmatic control over everything"
The only way I can see of reconciling these two mindsets is for Talon to become a compositor -
@fireborn So my reading of what he said is that we can't simply demand to have unrestricted, intrusive access to the whole desktop environment simply because that's how we (assistive technology developers, myself included on Windows) have always done it. We need to design new protocols that meet both accessibility and security requirements at once, without compromising either.
@matt @fireborn IMO you can have this access, and you probably do need this access. However we should give this access only to accessibility tools, and not to other software that could abuse it heavily
The parts of Newton that have landed so far already give accessibility tools like Orca higher privileges than normal apps, so that mouse review and key bind grabbing work. The same API could ferry around AccessKit data to the AT, but also give it the ability to see the screen for OCR, and so on
-
@fireborn yeah, I feel like the Wayland mindset is "these things are the compositor's responsibility, any exceptions need to go through a limited protocol and have their use cases thoroughly vetted to prevent abuse"
And the Talon mindset is "the user knows their accessibility needs better than me, so I will give them complete, straightforward programmatic control over everything"
The only way I can see of reconciling these two mindsets is for Talon to become a compositor@fireborn Like, the reason there is this enormous maximalist list of demands for what Wayland needs to provide to support Talon is because that is how Wayland structured itself. It is designed to place all the power in the compositor, and to prevent any other component in the system from co-opting that power unless there is consensus that there is a good reason and it can be done in a controlled manner. Under that framework there's no other possible outcome.
-
@matt @fireborn IMO you can have this access, and you probably do need this access. However we should give this access only to accessibility tools, and not to other software that could abuse it heavily
The parts of Newton that have landed so far already give accessibility tools like Orca higher privileges than normal apps, so that mouse review and key bind grabbing work. The same API could ferry around AccessKit data to the AT, but also give it the ability to see the screen for OCR, and so on
@AdrianVovk @matt Totally agree. That's why a permissions system is important. Mac OS does this really well, seperating permissions for view/control into Accessibility, screen recording, and input monitoring. This gives users control while also not simply granting access by default.
-
@AdrianVovk @matt Totally agree. That's why a permissions system is important. Mac OS does this really well, seperating permissions for view/control into Accessibility, screen recording, and input monitoring. This gives users control while also not simply granting access by default.
@fireborn @matt We've got a permission system: portals.
However this permission is so so dangerous that we shouldn't let arbitrary apps even ask for it. People tend to click "yes" through prompts. Your web browser should never prompt for AT-level access to the system. Thus we've been avoiding designing "especially dangerous" portals, like what an Accessibility portal would be.
However we now have "entitlements", which I proposed partly for the accessibility purpose. (1/2)
-
@fireborn @matt We've got a permission system: portals.
However this permission is so so dangerous that we shouldn't let arbitrary apps even ask for it. People tend to click "yes" through prompts. Your web browser should never prompt for AT-level access to the system. Thus we've been avoiding designing "especially dangerous" portals, like what an Accessibility portal would be.
However we now have "entitlements", which I proposed partly for the accessibility purpose. (1/2)
@fireborn @matt with entitlements, apps have to declare what portals they will attempt to ask for. This way accessibility tools have to be labeled with an entitlement before they can ask for such a dangerous permission.
Then the app store has the ability to review if the entitlement makes sense. A web browser that tries to claim that it's an accessibility tool will be against app store policy and will not be published.
Thus: we make it safe to have a hyper-privileged accessibility API (2/2)
