That said, if we're talking about web accessibility, the obvious recommendation is the WAI WCAG. Maybe not the best reference for learning on how to implement things, but its a good start.
Depending on the platform you're at home with, there are screen readers (NVDA, Orca, BRLTTY) which are open source and can be studied. On the user side, and on the "how is this implemented" side.
Installing NVDA on Windows and turning the monitor off is a good way to get your feet wet. It might feel strange at first, but you will notice that things can actually get done this way. Its also a good way to test a website if you have no specific accessibility knowhow yet. Just try to navigate and read its contents.
Is it weird that I, as someone with normal sight, had never thought of that as a simple way of testing whether your software (and the whole operating system together with it) works correctly with screen readers? It's like there's some sort of unconscious bias which links typing on a computer with its monitor being turned on.
And I lived through the times when most computers didn't come with any pointing device, which led to most software back then being accessible to keyboard-only users (notable exceptions being things like Paintbrush, which required a mouse), so I understand the link between the lack of a device and software being designed to work well without that device.
I don't currently have Windows. Is there a good way for me to test accessibility on Linux? As a fallback, I will get myself Windows once I port the tools to Windows, so I could test accessibility then.
Which brings me to your second question. Linux has a GUI accessibility API as well, the AT-SPI. GNOME Orca is the screen reader to use on Linux. If your distro configures things right by default, you should be able to access your Qt application with Orca as a screen reader on Linux.
For getting confirmation (like when I've got a first version of my app), do you have a suggestion for a forum where to ask?
I agree. If the features are well-designed, then they can be good for many uses, whether or not you are blind.
You could also add pronouncing file (especially if a document is using unusual words), it is useful if you are blind and using synthesized speech, but also if you are not blind and do not know how is the word pronounced then you can easily learn. (Likewise, if you watch television then you can put on caption in case you do not know how to spell some unuusal word (such as someone's name). Captions could also be useful for a "caption scrollback" menu to display prior captions in a list, although I have never seen this implemented, but I think it would be useful.)
Another situation where speech synthesis is often used (by people who are not blind) is GPS-based navigation systems. They often pronounce the street names wrong, so adding data for pronouncing, and then implementing that properly, would be better.
(I have mentioned before that I think that adding a "ARIA view" (with user-defined CSS) might be a best way to make a consistent visual display which uses ARIA instead of the visual styles defined by the web page author (widgets, etc can also be used, and would also be consistent instead of each web page having its own widget styles). However, I have not seen such a thing implemented in a good way.)
I think they are mostly focused on college level exercises, but if your kids are doing coding I'd imagine their tutorials would be something to take a look at: https://teachaccess.org/initiatives/tutorial/
As a complete aside for anyone reading this post, I think of improving accessibility as the "curb-cut effect", curb cuts (those ramps on sidewalks while cross streets) were created to improve urban access for those in wheel chairs, but also make it easier to use strollers, bikes, carts, and really for everyone walking in a built environment. When we as technologists make design decisions to make things more accessible I believe we end up with better products for everyone.