
For software that is cross platform and accessible, forget about Qt - kasabali
https://blind.guru/qta11y.html
======
bjpbakker
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.

[1] -
[https://bugreports.qt.io/browse/QTBUG-53024](https://bugreports.qt.io/browse/QTBUG-53024)

~~~
jnbiche
> 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.

~~~
bluGill
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)

~~~
jnbiche
> 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.).

------
mb720
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.

~~~
tinalumfoil
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.

~~~
mb720
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.

~~~
MBCook
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.

And they're probably frustrated as hell.

~~~
mb720
The comment you refer to was about how programmers getting yelled at on the
mailing list of the Linux kernel and how that's not OK.

The comment you refer to wasn't at all about Qt and the article about
accessibility.

------
dom0
> 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.

------
kazinator
> "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._

[https://www.nvaccess.org/about/our-
story/](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)."

------
kuschku
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.

~~~
oblio
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](https://www.jwz.org/doc/cadt.html)

~~~
ktta
The link is interesting. Looks like it checks for the HN's user logged in
cookie and redirects to imgur.

~~~
distances
No, it's checking the referrer. Cookies can't of course be read by other
sites, that would break everything.

~~~
ktta
I wasn't thinking about the cookies part.

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...](https://chrome.google.com/webstore/detail/referer-
control/hnkcfpcejkafcihlgbojoidoihckciin)

~~~
yoz-y
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.

------
alsadi
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.

------
kronos29296
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.

~~~
MBCook
Microsoft and Apple put a lot of time/effort into making sure their libraries
provide the necessary support so people can write accessible software.

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.

~~~
yoz-y
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.

~~~
MBCook
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.

~~~
yoz-y
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.

~~~
MBCook
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.

------
falcolas
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.

~~~
ivm
It's much worse: Chrome takes performance hit when accessibility is enabled,
so does Electron:

[https://github.com/electron/electron/issues/7206#issuecommen...](https://github.com/electron/electron/issues/7206#issuecomment-267912698)

So they are inaccessible by default at least on macOS while Safari and native
Cocoa apps are always accessible.

------
devwastaken
In this case, they mean "accessible" as in screen readers and assisted usage.

~~~
pavlov
Isn't that the usual meaning of accessibility in software?

~~~
LeifCarrotson
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.

~~~
amake
> 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.

~~~
LeifCarrotson
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.

~~~
LeoNatan25
That’s my experience as well.

------
enqk
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.

~~~
toyg
Did you have a commercial support contract for Qt at the time? What I've heard
is that they do fix things, if you are a paid-up customer.

 _> 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.

------
delYsid
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.

------
CreMindES
Did you implement your UI with widgets or QML?

~~~
malkia
That's what I've been thinking...

------
luord
> 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.

------
ndc33
summary - biased rant - don't bother reading.

------
jancsika
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

------
0xFFC
I upvoted you. But completely disagree. Qt does have serious shortcomings, but
it is _the_ only library I have seen could come this far.

