For software that is cross platform and accessible, forget about Qt
blind.guru
blind.guru
I don't believe anyone in the QT team is /against/ stronger support for accessibility. IMO it is understandable that fixing some piece of proprietary software is not a top priority. I believe it's more appropriate for the author to rant against JAWS for not caring about QT, than the other way around.
> Free Software is NOT about Accessibility or equality
The author is correct here. Free software is not about a specific feature, it's about protecting user's freedom. I believe the author would be warmly welcomed to discuss issues and submit patches - even fixing issues with proprietary software. He shouldn't blame a community of volunteers for not fixing his personal problems for free.
Worth pointing out, JAWS is proprietary, but it is also very widely used. I'd imagine its user-base is many, many times that of NVDA (which is the open source equivalent).
Substituting it for "the most popular proprietary screen-reader software" still doesn't change anything on my opinion though :)
So, yes, open source programmers are perfectly within their rights to ignore that audience, and that audience is perfectly within its rights to not use open source software that doesn't meet their accessibility needs and to warn others and advocate against the use of such software.
Marketing at its finest. /s
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.
First, the Qt company sells a commercial license for $79/month so that you can use the software without GPL restrictions. The author didn't mention if they were using that or the open source version. Either way, Qt is at least partly a commercial venture.
Second, there is a huge difference in the size of the respective projects if your projects only had you as the maintainer. It's not that easy to contribute to large projects. Also IMO, it behooves the larger projects to try and make their users happy especially if they want to remain alive.
Finally, upon reading the article you can see that the author is not expecting free help in any way. He is simply saying that if you want Accessibility then don't use Qt unless you can implement it yourself.
Red Hat, Ubuntu and the like employee some people who will sometimes implement a new feature for you - but those companies want you to buy a support contact for features. There are a number of foundations that pay people to work on free software (FreeBSD, KDE, Mozilla, many more) and so they will be more responsive to requests - but foundations are always lacking in money so they cannot do every feature they want.
There are a few "college students" (possibly retired) who work on things for fun. If they take an interest in your request they will do it. However they also have other things do to as well.
I believe the majority of people working on open source projects are like me: they work on things someone pays them for but do not have the time to do anything for someone else.
Note, industry coding is like this as well. They have money, but never enough to do all ideas. (and even if they did man-month issues mean they often can't do it anyway)
To be fair, I've also occasionally had people pay me to add features to my project. However, most of the work I've done has been volunteer, at no charge.
Also, I'm not sure I agree that the majority of people working on open source projects are like you. Perhaps the more popular projects have one or two individuals working like you, but even then, there are a lot of commits coming in from volunteers. At least, that's my impression from the frontend community (JavaScript) and functional programming communities (Scala, Haskell, etc.).
> "The JAWS people didn't answer emails when we reached out to them (admittedly quite a while ago), so we've been focusing on NVDA support. Patches to improve the situation with JAWS are welcome. Note that we may eventually implement UIA as opposed to IAccessible2, but that work is currently going slow."
That, to me, is a perfectly reasonable and polite response. "JAWS didn't care about us so we've worked with others. If you can help, you're more than welcome. Things might get better at some point anyway but it will take a while."
> Free software is not about a specific feature, it's about protecting user's freedom.
"Free software protects people's freedom (except the disabled, they're stuck with proprietary stuff, too bad)." That's not exactly a rousing motto. If anything the disabled are who should be helped most given how rediculously expensive accessibility software tends to be. It seems hypocritical compared to the usual messaging coming from the free software movement.
> He shouldn't blame a community of volunteers for not fixing his personal problems for free.
If free software wants to replace proprietary software this attitude doesn't work well. These aren't his personal complaints, they're problems for anyone with serious vision problems.
Especially since age causes everyone to be disabled somehow, and you're one accident away from being disabled in the prime of your life.
Consider it a form of insurance, if you must. You put forth a bit of effort into accessibility (in its many forms) now so you can keep using things later.
What more should we expect of him?
"No problem. Qt works on Linux, Mac and Windows, and if you find any problems, just report them to us and we are going to fix them."
However without a direct quote, it's hard to tell if that's an accurate representation or not.
It seems to me that you're just repeating the author's point, but with a different tone. Issues of "blame" aside (what does that even mean?), his point is that open source software tends not to meet the needs of the accessibility community. One possible cause of this is that the devs who support open source software tend not to be disabled and tend not to have experience or even access to things like screen readers.
I honestly don't know enough about the issue to know how true this might be, but just dismissing it as a rant, even if the word "rant" is correct in this case, doesn't address the underlying issues.
BTW, a quick google search suggests that JAWS is far and away the most popular screen reader for windows. If it's not a priority, then accessibility for windows isn't a priority either, which is exactly the author's point.
> The JAWS people didn't answer emails when we reached out to them (admittedly quite a while ago), so we've been focusing on NVDA support. Patches to improve the situation with JAWS are welcome. Note that we may eventually implement UIA as opposed to IAccessible2, but that work is currently going slow.
So they tried to work with them, but they did not reply. How are they supposed to fix the issue?
If they had been clear up front about their accessibility support, I doubt this would have been an issue in the first place.
That's survival bias: Those who can't are not Linux devs.
That's bullshit. I mean, that's one of the main reasons I never bothered submitting a patch for Linux. Many of us really don't like being told off for what we're doing as a volunteer. I reluctantly can accept a limited amount of abuse for a paid project, but my tolerance for abuse for what I do as a volunteer is zero.
Of course, when somebody introduces bugs, that's a problem and should be talked about. But you can do that respectfully without sugarcoating the affair.
That's not how you treat people, especially if you want them in your community. This isn't someone complaining that the 'close' button window control was moved to the wrong side. They've lost their ability to use a large chunk of free software and no one (more or less) cares.
And they're probably frustrated as hell.
The comment you refer to wasn't at all about Qt and the article about accessibility.
Whereas a big majority of proprietary software vendors don't care about users on non-mainstream platforms, whether or not those users have 20/20 vision or are completely blind.
> "If Free Software ever takes over, the blind will be unable to use their computers."
Does not follow from the observation that free software applications and libraries don't quite meet all of their functionality on Windows and haven't made it a priority to support accessibility. (For one thing, as long as we're using Windows, free software hasn't taken over.)
> "While other screen readers seemed to work (NVDA) it is simply not feasable to ask my future users to switch to a different screen reader just for a single program."
A screen reader should handle anything, even a program that implements its own font and pixel-pushes it to a canvas (there is OCR for that).
Anyway, what is this NVDA which can read from text fields in GUI widgets that the 'leading brand' reader doesn't handle?
NVDA is open source software, which means the code is accessible to anyone. This enables translators and developers around the world to continually contribute to its expansion and improvement.
https://www.nvaccess.org/about/our-story/
Thus the argument appears to be: "free software libraries don't support accessibility on Windows, other than through the use of a screen reader that is free software, translated into 43 languages, used by people in 120 countries, and a winner of multiple awards. Free software are just hipsters who don't give a damn are in it for self promotion and to just address their own requirements (and none of them are visually impaired)."
Regarding marketing qt or gnome as accessible it means in a specific setup with a specific set of working readers in the opensource/freesoftware eco-system
Not accessible to all possible setups. Specially proprietary readers?
You have paid nvidia for your gpu card, don't ask me volunteer to fix their properietary driver compatability with your opensource game.
Now, Qt is an open project, so the question is: are there just no users interested in this who could implement it themselves? Most other functionality in toolkits was implemented like this.
If I recall correctly Sun paid a long time ago for usability and accessibility studies for GTK 2 and Gnome 2. And I'd guess most of their work was thrown way during the transition to GTK 3/Gnome 3 (somebody can correct me on this, I'm not really certain). Basically: https://www.jwz.org/doc/cadt.html
I just learnt about Referer. How doesn't this compromise privacy? Looks like I'm woefully uninformed about web security/privacy.
Also, found this[1] for anyone who just learnt about this like me.
For firefox, go to about:config and set Network.http.sendRefererHeader to 0
[1]:https://chrome.google.com/webstore/detail/referer-control/hn...
Granted it is not very secure but some people will go to great lengths to break the open web.
This is also how Google Analytics knows where people come to your site from, for example.
Eh?
I worked with a blind programmer. He loves Linux, but had to stick to Windows because the accessibility for blind people on Linux was horrible compared to JAWS.
That said, I suspect the easiest solution nowadays would be writing your UI in electron, or the Gecko-based project that was announced a week or so ago (sorry, I can't remember the name).
Makes me hesitate to assume Electron apps are accessible by default
Many cycles ago I wrote a tool which brought Unity-like menu search to Windows, and also used the accessibility API to do this (IAccessible, I think). Even back then there were many apps which didn't expose anything there, even from MSFT.
Individual programs may be bad, but the toolkits support it.
Here, none of the cross platform toolkits seem to even have the most basic support.
- For-profit organizations have little incentives to develop accessible software or they have to make it prohibitively expensive - Open Source development is usually "itch my scratch"-driven (as the author points out) and the pool of people who are both motivated by their own plight and able to develop solutions for them are very few.
I think this is the main reason why the best accessibility frameworks are made by companies that are already far away from their bottom line and can afford to do the work at their own expense.
MS may or may not care, but accessibility is often a requirement for government contracts (or buisnesses who want government contracts) so it's a good sales feature for them, even if something if a checkbox feature. They work very hard at t too.
But the end result is that both of them work really hard on accessibility and everyone benefits.
Apple (from what I have heard MS too) really does amazing work in accessibility but this would not be possible had they not had enough resources. I can understand why understaffed open source projects do not allocate more resources to accessibility.
https://finance.yahoo.com/news/david-pogue-on-iphone-voiceov...
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.
It sounds like, from this article, Java is a workable (if not well suited for a C++ driven backend). Of course, cross-platform shims aren't that hard, just time consuming.
https://github.com/electron/electron/issues/7206#issuecommen...
So they are inaccessible by default at least on macOS while Safari and native Cocoa apps are always accessible.
To them, "accessible" has its conventional or conversational definition: able to be accessed, or available. They would view the title as describing software that you can install or run on any operating system, which QT seems to supply.
I find it hard to believe that software developers would not be aware of the term "accessibility" as meaning features facilitating use by handicapped users.
- Me: On HN enough to know what it means.
- Senior EE in PLC programming: No clue.
- Senior dev, mostly self-taught: Means it can be accessed? Easy to use, or intuitive?
- College Intern: It means it's able to be used by people with disabilities.
(Senior dev: Oh yeah! I read an article on that a while ago.)
So our shop was 2/4 on it. Granted, we're a little atypical, but as a lot of programs are written with no thought to accessibility, there are a lot of devs who don't think about accessibility.
I suspect we'd have similar results for 'localization'. They'd probably guess 'internationalization' from context.
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.
> you have to be ready to pay a contractor to do the necessary QT adaptations/fixes.
Admittedly a few years ago, the problem was that there were very few such specialists around.
IOW, not supporting JAWS is just not an option. Besides, Qt doesn't work with Narrator either. It is telling if your accessibility support doesn't work together with the screen reader provided natively on a specific platform. So it is really not about JAWS. Qt's Accessibility support on Windows is just not up-to-date and bitrotten to a point where it is no longer useful to endusers.
If there's a screen reader that works then the problem isn't with QT. This complaint should be aimed at the software that doesn't work or does only selectively; not at the people working for free who ultimately did provide accessibility.
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