This article isn't anything more than a rant. The author filed a bug in the QT issue tracker [1] that some proprietary screen reader (JAWS, that his customers use) does not work well with QT on Windows. No (technical) details provided whatsoever.
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.
> 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.
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).
It is not a realistic option for an author of accessible software to ignore JAWS. Obviously, open source software has no obligation to support accessibility, but that means that it'll be used less (this does not just affect visually impaired people, but also organizations and companies that have a need or obligation to keep their systems accessible; ADA compliance, for starters).
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.
I'm not sure about that - it also mentions that Qt is incompatible with Microsoft Narrator. If it doesn't work with the screen reader that comes bundled with the operating system, it suggests Qt is doing something wrong.
> 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.
I don't think comparing your hobby projects to Qt is apt here.
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.
I do get paid for the project I maintain, but ONLY when I am doing something that benefits my employer. I became maintainer because my employer needed a feature that wasn't there so they paid me to write it. That makes me someone who cares enough to be maintainer (the previous maintainer didn't want to be maintainer anymore). If you submit a good patch I will accept it. Submit several good patches and I'll make you co-maintainer (so far that hasn't happened). If you ask an easy support question I'll answer. If you want a new feature or have a hard support question - my employee doesn't pay me for that and I have kids to play with on my own time.
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)
> 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.
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.).
I agree, especially if you look at the comment on the bug:
> "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."
JAWS is a very popular screen-reader, not just "some proprietary screen-reader". Probably the most popular screen-reader, although it no longer has the market dominance it used to.
I think his point is that you can't claim 'user freedom' and 'software for the people' if you ignore a chunk of the populace.
> 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.
QT promised something it couldn't (wouldn't?) deliver upon. Given that the author explicitly wrote them with questions about it and was effectively lied to, his ire is both understandable and justified IMO.
They don't mention any screen readers; their documentation only calls out backend accessibility specs without any mention of popular specs (UIA) they don't support.
> He shouldn't blame a community of volunteers for not fixing his personal problems for free.
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 bug report is just prosa. No simple test case is attached to reproduce his problem. I think he did not even start a debugger. So what does the guy expect. Maybe it is just some broken string conversion. But without a bit investigation on his side he will never find out. Only well paid support will waste time with that kind of horrible report.
JAWS is what a large number of blind and low vision people use. Just because you're not familiar with it doesn't mean it is "some proprietary" thing that should be ignored.
I get that the author is frustrated with false claims about Qt, but calling people working on open source software "hippie coders" is just an insulting misrepresentation harming any rational debate.
I don't understand how people can be so entitled about free software. Especially given the reply by the Qt developers:
> 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?
It is accessible, just not with some specific software. From what I can see, they tried to solve it, but could not due to lack of cooperation by the software's creator. Maybe they should have spent more effort, but then this was not a paying customer apparently.
That specific software is the most popular software in use on Windows. That makes it something of a required use-case if you want to claim accessibility on Windows.
I think ive read enough LKML to realize name calling doesn't slow software development and free software devs can handle being told off once in a while.
> free software devs can handle being told off once in a while
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.
When I provide code for free I want to be treated with respect.
There's evidence that this is not always the case when working on the Linux Kernel.
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.
This author wants to be treated with respect. They want to be to able to use free software too. But the projects are basically telling them 'too bad'. And when projects break stuff that's critical to his/her use the response is... oh well. If anyone ever fixes it we'll take the patch.
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.
> 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.
> "And no other Free Software toolkit for that matter, because they basically all dont give a shit about accessibility on non-Linux platforms."
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.
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)."
But you paid jaws, and got qt for free as a favor and you are blaiming qt. You are a customer of jaws ask them to contribute to qt.
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.
So, to recap, GTK doesn't work at all for accessibility, wxWidgets has issues with text entry, and Qt works, but only with NVDA, and not with text entry fields and JAWS.
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.
These are the things that are super low priority for commercial projects, and those don't usually want to leave money on the table. They're super low priority for OSS.
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
Not sending a referer can sometimes break sites though. For example some image hosting sites will not display content if you are not coming from their domain (to avoid hotlinking) and some web-apps will kill deep linking like this.
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.
>The only users that are interested and can implement it themselves already use linux where accessibility works better than on windows or with JAWS.
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.
Maybe because it's easier to solve the immediate problem by writing the UI in the target platform's native fully-accessible toolkit and dropping support for platforms that don't have one.
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).
I use a lot of accessibility apis indirectly for keyboard navigation, on macos Shortcat cannot find any elements to click inside Google Chrome or VSCode which makes me wonder if either Shortcat has a bug or Google Chrome is not exposing those elements through the accessibility api.
Makes me hesitate to assume Electron apps are accessible by default
> I use a lot of accessibility apis indirectly for keyboard navigation
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.
Somehow the author assumes that the native gui has better accessibility features. In a world of bloated frameworks and browser as a gui type apps not every app is accessible. Most of the time it isn't even on their radar because of the tiny user base. One of those things that is just plain wrong when you spectate but when it is your job to do you find it a pain to implement.
Sadly accessibility development has many roadblock on its path:
- 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.
Apple seems to do it because it's in their ethos. Jobs and Cooks have both said it matters to them. They aren't big in enterprise (or even education) so I don't think that argument fits. I think they just care. That may be a bit of my bias but I can't come up with a good business case for them.
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.
Yes that is what I meant. Apple and MS are for-profit, but they have massive profits from something else and a huge safety net. This is opposed to a company that either makes accessible software specifically, or makes software that would benefit from being accessible (let's say an IDE such as IntelliJ).
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.
My point with MS is that they're not doing it out of the good of their hearts (for argument) and just spending their profits... they are REQUIRED to do it to be able to get many of their biggest contracts. They are doing it so they CAN sell.
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.
So, I'll toss this question out there: Is Electron or React Native better in this regard? Making the assumption that JAWS is capable of reading into HTML in Chrome as a browser, I would expect that it's capable of the same in Electron.
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.
Yes, that is the specific, in-context meaning - but many people, even software developers, don't know that.
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.
> but many people, even software developers, don't know that
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.
Quick poll of my coworkers (we do industrial automation, there's next to zero thought or money given for accessibility except the awareness that start and stop buttons, typically red and green, must also be labeled in case users are red/green colorblind:
- 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.
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.
Well, not supporting JAWS is like claiming you are big in the transportation bussiness, and when someone comes up to you with a car, you end up
explaining "Oh, but we only do horse carriages." Not supporting JAWS is just not an option. The fact that JAWS is proprietary is irrelevant here. It is simply the most wide-spread screen reader, period.
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.
> 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
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.
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...)
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.
[1] - https://bugreports.qt.io/browse/QTBUG-53024