UI accessibility infrastructure across platforms and programming languages (by AccessKit)

Accesskit Alternatives

Similar projects and alternatives to accesskit

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better accesskit alternative or higher similarity.

Suggest an alternative to accesskit

accesskit reviews and mentions

Posts with mentions or reviews of accesskit. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-06-17.
  • Fyne, a cross-platform GUI toolkit written in Go
    8 projects | | 17 Jun 2022
    Would you be willing to consider using a non-Go library via a C API for this? I'm working on AccessKit [1], a cross-platform abstraction over the various platform-specific accessibility APIs. It's written in Rust, and it doesn't yet have a C API, but that's planned. I'm aware that using cgo complicates build requirements, particularly on Windows, but it looks like you're already dependent on cgo on Windows (unlike, say, Gio).

    [1]: I know I haven't yet done much with it this year. Hopefully I'll start doing substantial work on this again in the next few weeks. Threads like this one remind me that the world is waiting.

  • I don't want to go to Chel-C
    3 projects | | 11 Jun 2022
    > we'd even say that the greatest programmers are so because of how they produce redundancy.

    Perhaps the greatest of all programmers produce redundancy while depending on very little of it in their own code. For example, Richard Hipp created SQLite, the ubiquitous and amazingly high-quality embedded database, in C. Thinking about that makes me feel like I ought to be using C in my own, much more modest attempt at a reusable infrastructure project [1].

    [1] (it's too late now, I'm committed to doing it in Rust)

  • Show HN: Warp, a Rust-based terminal for the modern age
    39 projects | | 5 Apr 2022
    > We are actively working on a11y!

    Glad to hear it! I'm working on a Rust GUI accessibility library that might interest you:

    If you'd like to email me so we can compare implementation approaches and perhaps avoid duplicated effort, my email address is in my HN profile.

  • Why (Enterprise) Software Is Bloated
    1 project | | 3 Mar 2022
    The article strikes me as being dismissive about accessibility, merely describing it as a legal requirement and source of bloat. For a lot of software, I'd say it's a moral imperative, and that's why it's a legal requirement. I'm afraid that the treatment in this article will encourage developers to ignore accessibility in useful applications that could in principle be accessible, and these applications will then become required for jobs, education, etc., thus erecting new barriers for disabled people. But now that someone has directly linked accessibility to bloat, I guess I should make sure that my own in-development solution for cross-platform GUI accessibility [1] can never be described as bloated.


  • CXX-Qt: safe Rust bindings for Qt
    9 projects | | 2 Mar 2022
    > from personal experience working on GUIs and toolkits for decades i think are overblown)

    Accessibility and internationalization are really hard though, right?

    I'm finally doing something about the accessibility issue: Still have a long way to go though.

  • Big Time Public License
    1 project | | 13 Jan 2022

    If I understand the synopsis of that article correctly, I don't think that concept applies here. Unless I've got my history wrong, our dominant standard for what's considered free software or open source, the Debian Free Software Guidelines (later repackaged as the Open Source Definition, wasn't the result of some kind of broad consensus among developers, users, and/or distributors. As badsectoracula pointed out [1] [2], source-available licenses with restrictions used to be more common. But Debian was always strongly aligned with the FSF's ideology; if I'm not mistaken, it was originally funded by the FSF, and of course, the full name of the main Debian distro is Debian GNU/Linux.

    > The unusual foibles and preferences of specific people who are firmly in the history of FOSS are not relevant factors here. The relevant factor is drawing and maintaining a strict definitional line

    My point is that this strict definition reflects nothing more than the MIT AI Lab hackers' elevation of their freedom (even at the expense of others, as in chapter 5 of _Hackers_) to an ethical absolute. Of course, most of those hackers outgrew that, but Stallman didn't, and he successfully spread the idea that all generally useful technical information, including software, should be freely available. And, if I'm not mistaken, that's where the DFSG came from. Since I didn't spell out part of my logic in my original comment, I will here: given that his nearly-forgotten campaign against passwords was obviously hopelessly naive, we should be open to the possibility that the same holds for the idea that software should be free for everyone to use.

    > There's been a massive push in recent decades towards permissive licenses

    Fair point. And I admit that this has made me stop and think about my choice of license for my own primary open-source project, AccessKit [3]. I was quick to permissively license that project from the beginning, before I considered funding. As it turned out, most of my development on that project so far has been funded by Google, which also specifically requested the Apache license (I went with the Apache/MIT dual license common in the Rust world). But in any case, I think a permissive license is actually the best choice for my goal with this project, which is to encourage and help developers to make as many GUI applications as possible accessible to disabled users. So yes, I want frictionless adoption above all else, but I think it's for a good reason. If a massive company used my project without paying me, I think I would consider it a net positive, because at least more applications would be accessible. But then, it's possible that by choosing a permissive license, I'm further poisoning the well, because I'm making more software available to freeloaders who would otherwise be obligated to pay someone (not necessarily me). FWIW, I'm thinking about developing an AccessKit-based module that has more of a niche use case (a screen reader for platforms or embedded devices that don't already have accessibility support), and for that, I might go with a dual copyleft/commercial licensing scheme.




  • Attempt at building a multi-platform UI project (with cross-compiling)
    3 projects | | 9 Jan 2022
    You generally need to use either platform-native GUI toolkits (like winapi and cocoa), or one of the big toolkits, ie. GTK or QT to get accessibility support. The AccessKit project is aiming to make it easier for smaller toolkits to support accessibility APIs, but it's not quite there yet.
  • Is it worth writing a GUI toolkit in Rust?
    5 projects | | 7 Jan 2022
    Fortunately, it seems like new GUI toolkits will have an easier time of integrating with accessibility APIs in the near future thanks to AccessKit. It's Windows-only for now, but support for other platforms is planned.
  • AccesKit: UI accesibility infra across platforms and programming languages
    1 project | | 27 Aug 2021
  • Iced: A cross-platform GUI library for Rust, inspired by Elm
    19 projects | | 27 Aug 2021
    For those (like me) just hearing about AccessKit, I assume it's this:

    Neat! I really like the Rust ethos of creating modular cross-platform adopters (e.g. winit, getrandom), and from a brief skim this seems to fit that model.

  • Psst: Fast Spotify client with native GUI, without Electron, built in Rust
    20 projects | | 16 Aug 2021
    > it'd take awhile to perfect

    Some of us can't wait. That's why I, for one, continue to advocate for developers to make their applications accessible with the currently available tools. It's also why I'm trying, with my AccessKit [1] project (which admittedly is taking time to get off the ground), to make it easier for GUI toolkits to implement the current baroque platform accessibility APIs.

    I'm also reluctant to concede that we're doomed to reconstruct UI content and semantics probabilistically from pixels, when that information is already there somewhere in the app. But it may be the best long-term solution to the social problem of trying to get everyone to implement accessibility.


  • AccessKit: Cross-platform UI accessibility infrastructure
    1 project | | 13 Aug 2021


Basic accesskit repo stats
about 1 month ago

AccessKit/accesskit is an open source project licensed under BSD 3-clause "New" or "Revised" License which is an OSI approved license.

Developer Ecosystem Survey 2022
Take part in the Developer Ecosystem Survey 2022 by JetBrains and get a chance to win a Macbook, a Nvidia graphics card, or other prizes. We’ll create an infographic full of stats, and you’ll get personalized results so you can compare yourself with other developers.
Find remote jobs at our new job board There are 4 new remote jobs listed recently.
Are you hiring? Post a new remote job listing for free.