For software that is cross platform and accessible, forget about Qt

When I worked with QT as a UI framework, I did regularly get a sense that the QT contributors were understaffed, and that they have barely enough time to deal with the huge scope that the framework is attacking.

The conclusion was that, if you desire to use QT, you should get yourself prepared to dive in and fix things yourself. This sort of defeats the point of using a cross platform framework, since you may have to become a platform expert.

Alternatively you have to be ready to pay a contractor to do the necessary QT adaptations/fixes.

> He shouldn't blame a community of volunteers for not fixing his personal problems for free.

Please allow me to highlight this statement. I encountered it so frequently when I created and maintained several popular open source projects. I honestly think a lot of people assume that if you're working on a project, you must be getting paid for it. Then again, many of them were totally unfazed when I pointed out that I did all the work unpaid, and that it was a hobby project.

Possible lesson: if you have a chance to go with standards-based software, choose it every time.

Example: I chose nw.js over Qt for a cross-platform frontend. It's interesting to compare the author's starting research to my own.

Author: needs feature X, reads Qt docs, emails the sole person responsible for feature X. Gets the impression that X either works or will work with a quick bug-fix turnaround time. Is wrong. Is frustrated.

Me: needs feature X, reads Mozilla docs, Microsoft docs, 5 blog entries, and a virtual grocery isle of framework demos that deliver X in various ways, emails a blog author about one of 3 different ways to implement X. Gets told that my way of implementing X isn't one of the two ways everyone else is using. Still, it seems to work ok, so I don't end up falling back to one of the other two possible ways of solving X.

Also-- I try out a few demos by viewing a web page in any browser. I change the demos to suit my own use case by clicking a few keys and perusing the code in any browser.

Aside: I think my final app works by default with JAWS-- at least the text content of the relevant divs should get read properly.

To drive it home a bit more: the most trouble I've had in the front end is from the nw.js window menubar API. It is well-documented. It is easy to understand. The author has been responsive in fixing bugs. But guess what-- it isn't an HTML5 standard API, so it hasn't been tested, documented, revised, and argued about by at least three large companies with a vested interest in it working well. The result is my dev time (e.g., how does it interact with DOM bubbling, does it interact with DOM bubbling the same way on each platform, how does my implementation work with OSX's app menu, how does my placement of "Preferences" work with Apple's HIG, how does it affect window dimension measurements, how does its rendering relate to the various events that tell me when the page has loaded/painted, on and on...)

Edit: protect against pedantry

That’s my experience as well.

Writing accessible software is very challenging, and a lot of the documentation that has historically been available was typically sub-par. I usually try advocating in favor of web accessibility, but in many cases developers just don't know any better. I'd definitely count myself among those that still have a lot to learn.

I've noticed that the w3c is starting to push hard on improving the status quo, especially during the last few months. The latest WAI-ARIA Authoring Practices draft [0] is superb. It includes examples, documentation on the different keyboard interactions, and suggested aria properties.

As the documentation quality increases, it gets easier to raise awareness among developers. My experience has generally been that once you raise the point and you provide a clearly defined solution, many people are happy to make changes. For example, I've occasionally convinced friends with inaccessible video to either publish transcripts or write articles / blogs with the equivalent knowledge.

[0] https://www.w3.org/TR/wai-aria-practices-1.1/