10 ms·
For software that is cross platform and accessible, forget about Qt
- CreMindES 9y agoDid you implement your UI with widgets or QML?
- malkia 9y agoThat's what I've been thinking...
- devwastaken 9y agoIn this case, they mean "accessible" as in screen readers and assisted usage.
- pavlov 9y agoIsn't that the usual meaning of accessibility in software?
- Mayzie 9y agoYes.
- LeifCarrotson 9y agoYes, 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 9y ago> 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 9y agoQuick 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 9y agoThat’s my experience as well.
- kuschku 9y agoSo, 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.
- Asooka 9y agoMaybe 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).
- SwellJoe 9y agoAre they accessible? I know a lot of web toolkits and component libraries are not.
- slifin 9y agoI 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
- dom0 9y ago> 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.
- oblio 9y agoThese 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
- dom0 9y ago> 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.
- 0xFFC 9y agoI upvoted you. But completely disagree. Qt does have serious shortcomings, but it is the only library I have seen could come this far.
- nippples 9y ago> be me > read powerful article on Qt being shit on accessibility > "Sorry for claiming Free Software would be a good thing for the world." > I shall no longer let Free Software oppress the world > uninstall Firefox, Chromium > launch Internet Explorer > browse literally anywhere > All data is now held by ransomware, must pay my savings to bigd1ckd4ddy0 > The world is now a better place
- sctb 9y agoNot here, please.
- mb720 9y agoI 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.
- Sean1708 9y agoPlus it's a pretty big leap from "I can't use my favourite screen-reader" to "blind people can't use open source".
- tinalumfoil 9y agoI 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 9y agoWhen 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 9y agoThis 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 9y agoThe 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.
- bjpbakker 9y agoThis 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
- jrochkind1 9y agoJAWS 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.
- Brakenshire 9y ago> 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).
- bjpbakker 9y agoYeah sorry about that. Maybe "some" seems a bit too careless. Not intended that way. Substituting it for "the most popular proprietary screen-reader software" still doesn't change anything on my opinion though :)
- 9y ago
- deleted 9y ago[deleted]
- kronos29296 9y agoSomehow 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 9y agoMicrosoft 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 9y agoSadly 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 9y agoApple 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.
- falcolas 9y agoSo, 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.
- SparkyMcUnicorn 9y agoLooks like Electron is just as capable as a website: https://electron.atom.io/docs/tutorial/accessibility/ https://electron.atom.io/docs/tutorial/accessibility/
- ivm 9y agoIt's much worse: Chrome takes performance hit when accessibility is enabled, so does Electron: https://github.com/electron/electron/issues/7206#issuecomment-267912698 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.
- kazinator 9y ago> "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)."
- enqk 9y agoWhen 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 9y agoDid 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.
- jancsika 9y agoPossible 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
- ndc33 9y agosummary - biased rant - don't bother reading.
- alsadi 9y agoBut 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.
- luord 9y ago> 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.
- delYsid 9y agoWell, 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.