There are quite a few resources about the web, Microsoft and Apple also have their own documentation.
Nothing can ever beat the accessibility of a fully native UI, written with whatever toolkit is most popular on a given operating system. Yes, this means you need multiple completely different UIs, 1Password 7 style.
If you want to go cross platform and still be accessible, go with Electron. There's a lot of material written already on how to make web apps accessible, and that's basically what Electron is. Chromium's accessibility is top notch on Windows and Mac OS and pretty good on Linux (if you turn on a flag).
If, for whatever reason, you're not allowed to use Electron, QT and WX widgets also work, though there are certain controls that don't work that well on certain platforms, so you might need some really terrible workarounds. Same for Swing, which still requires enabling Java Access Bridge if I'm not mistaken.
I think the worst offender is GTK, it's pretty accessible on Linux, but completely inaccessible on anything else. The GTK developers have been promising changes in that regard for years, but I haven't seen those changes yet.
Custom toolkits, SDL based libraries and immediate mode GUIs are a complete no go. The operating system needs to know what kind of controls you have on the screen for a screen reader to work, but "draw a bunch of pixels here" is definitely not enough information, and that's what you get from those. You can implement each platform's accessibility APIs yourself, but that requires intimate knowledge of the platform internals (think COM on Windows) and is often poorly documented (there's almost no documentation for the Mac APIs). If you want to go that route, it's much easier to just go with 3 separate GUIs.
There's some ongoing work to change that state of things[1], but it's far from complete.
As the primary developer of the linked AccessKit project, I think this is a pretty good summary. I wouldn't call GTK the worst offender, because it is at least accessible on one platform. There are plenty of cross-platform GUI toolkits (e.g. Tk, FLTK) that don't even have that.
Nothing can ever beat the accessibility of a fully native UI, written with whatever toolkit is most popular on a given operating system. Yes, this means you need multiple completely different UIs, 1Password 7 style.
If you want to go cross platform and still be accessible, go with Electron. There's a lot of material written already on how to make web apps accessible, and that's basically what Electron is. Chromium's accessibility is top notch on Windows and Mac OS and pretty good on Linux (if you turn on a flag).
If, for whatever reason, you're not allowed to use Electron, QT and WX widgets also work, though there are certain controls that don't work that well on certain platforms, so you might need some really terrible workarounds. Same for Swing, which still requires enabling Java Access Bridge if I'm not mistaken.
I think the worst offender is GTK, it's pretty accessible on Linux, but completely inaccessible on anything else. The GTK developers have been promising changes in that regard for years, but I haven't seen those changes yet.
Custom toolkits, SDL based libraries and immediate mode GUIs are a complete no go. The operating system needs to know what kind of controls you have on the screen for a screen reader to work, but "draw a bunch of pixels here" is definitely not enough information, and that's what you get from those. You can implement each platform's accessibility APIs yourself, but that requires intimate knowledge of the platform internals (think COM on Windows) and is often poorly documented (there's almost no documentation for the Mac APIs). If you want to go that route, it's much easier to just go with 3 separate GUIs.
There's some ongoing work to change that state of things[1], but it's far from complete.
[1] https://github.com/AccessKit/accesskit