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 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)
-
@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)
@AdrianVovk @matt Ask for, no. But a user should be able to go in and add an app manually, in the case where an app is not distributed via an app store system. Not every app is going to request entitlements properly. Unless the app simply won't launch, then I think there needs to be a way around that.
-
@AdrianVovk @matt Ask for, no. But a user should be able to go in and add an app manually, in the case where an app is not distributed via an app store system. Not every app is going to request entitlements properly. Unless the app simply won't launch, then I think there needs to be a way around that.
-
@AdrianVovk @matt the future is sandboxing however. For security and privacy. I'm inherently in support of a system like this.
-
@AdrianVovk @matt the future is sandboxing however. For security and privacy. I'm inherently in support of a system like this.
@fireborn @AdrianVovk I'm not sure that it's possible to meaningfully sandbox assistive technologies. But I do think it's important to prevent arbitrary applications from claiming the privileges of assistive technologies.
-
@fireborn @AdrianVovk I'm not sure that it's possible to meaningfully sandbox assistive technologies. But I do think it's important to prevent arbitrary applications from claiming the privileges of assistive technologies.
@matt @AdrianVovk I don't think anyone is saying we should sandbox assistive technologies, just that applications shouldn't be able to arbitrarily access the things that assistive technologies need to function.
-
R relay@relay.mycrowd.ca shared this topic
