Even if you're not legally required to implement it now, and even if you don't think this is a basic human right (which you should), there are legal changes coming, and you never know when you will be forced to implement it.
If you choose a library with great accessibility support, even though your app might not be accessible initially, fixing this won't be that hard. If you choose a library without one, though, when the time comes, you will either need to completely rewrite your app using a different library, or dig deep into native OS code and figure out how to interface with accessibility APIs, which is not an easy task.
This is a risk/reward scenario. The downside of choosing a library that supports accessibility usually isn't that bad, putting personal feelings about Electron aside. However, if you need accessibility someday, however unlikely that might now seem, you really don't want to be forced to drop everything and focus on rewriting that GUI layer fast, before the regulators catch you.
It seemed very unlikely that game developers would ever need accessibility, so no one cared. Then, the US government mandated that all chat systems must be accessible, and a lot of games include chat systems. That was not a pleasant experience for anyone. You never know what is coming, and you don't want to shoot yourself in the foot.
Now for some pointers. Electron is fine. No, really, Electron, is, fine. There's nothing wrong with it. QT is fine too. GTK works, as long as all your users are on Linux, as accessibility for other platforms is nonexistent. Java works on Windows, not sure about Linux and Mac. Anything that uses native widgets, so WX and native OS frameworks are the best, but not everyone can afford the luxury of choosing those. Game frameworks and small, minimal libraries are a no go.