[zapzupnz]

I don't see that at all. Rather, each OS has its benefits, and if the person who designs a toolkit doesn't account for them, you wind up with something middling and foreign that takes advantage of nothing.

For able users, that can come down to minor irritations. For users with special accessibility requirements, that's downright unacceptable.

If my listing of all the features of macOS might have come off as haughty, it's simply because I'm one of the ones who has special accessibility requirements, and the way macOS does things suits me well. Apps that don't use Cocoa, therefore, can really screw me over.

[mwcampbell]

In your experience, how do web applications compare to native Mac apps? Of course, a web app can be accessible with both VoiceOver and magnification (based on all the features you listed, I'm guessing you're low-vision). But are even the most accessible web applications noticeably less efficient for you than native Cocoa apps?

[zapzupnz]

You're correct, I have low vision. Enough to code and read relatively comfortably, but not for long; so I either make the text enormous or turn on VoiceOver. Below, I'm talking about macOS; I don't use VoiceOver on iOS.

I tend to find with web apps that they're pretty inaccessible with VoiceOver, depending on what they were made with. If it's Electron or React Native, unusable. I just make the text huge. No good for blind users who shouldn't be left out of the fun, but mightn't even be able to find the voice chat controls.

Even when I'm not using VoiceOver, web apps tend not to respect system accessibility settings like text size. When they have them built into the apps as a setting, that's nice but rarely the case. It would still be better to respect my accessibility preferences; I don't go to all the trouble of setting them up for nothing. It's also not like Apple's accessibility APIs have changed drastically over the years, they're pretty stable. I imagine this to be the same for Windows.

In websites, it's usually a different matter, sometimes a bit better. In general, the web version (that is, in a browser) version of a web app is usable to a greater extent, though that doesn't necessarily mean anything, because VoiceOver knows how to inspect the DOM — whereas it isn't expecting that at all with 'native' web apps.

Proper Cocoa apps always win.

[mwcampbell]

Interesting. Based on your description, it seems that NVDA on Windows fares better with Electron apps than does VoiceOver on Mac. NVDA's "browse mode" features work equally well whether it's Electron, Chrome, or Firefox (and to a lesser extent in IE and Edge).

In another thread, you wrote that Xcode is the best IDE you've found for Mac simply because it's native to the Mac. Have you tried Eclipse? Given that Eclipse's SWT widget toolkit is based largely on native widgets, it might be native enough. Then again, the editor is custom, so it may still fall short.

I ask you these questions because I'm interested in the perspective of a Mac user who has apparently learned to make very effective use of multiple Mac accessibility features.

[zapzupnz]

I had to install Java and Eclipse to give it a try just to reply to this comment.

I never liked Eclipse, it always felt extremely non-native to me. Nothing much seems to have changed.

Right from the start, the Eclipse Installer (by Oomph, apparently) is a web app that VoiceOver has difficulty with meaning I have to interact with it using web navigation controls which is a pain when I'm not expecting it.

The rest of the interface was a bit hit and miss. Either VO could read what was on screen, or it thought I was looking at a table that apparently had no elements in it.

Turning VO off and clicking around, still definitely not a native experience, though better than I remember it. Native-handling of text, access to macOS Services… but only in certain parts of the program!

After poking around a bit more, it turns out the only places I could get native handling of text were web views (of which there are many); most text presents non-native controls to deal with things like copying and pasting, precluding the ability to use built-in Services.

Besides that, the way the app is designed was just foreign. Non-native paradigms for presenting information like those tear-off palettes (that turn into weird, full windows when torn off, rather than inspector palette windows; if you click the internal (non-macOS) minimize button on one of these windows, the window itself stays the same size, but the UI inside gets smaller, leaving this huge empty window with nothing in it.

I was curious to see what VO would say about this window. It was just as confused as I was, thinking one of the two remaining on-screen buttons was a checkbox. That's probably how it was implemented internally, but it was certainly not a checkbox. Once I clicked on the internal restore button, the rest of the UI came back, but VO couldn't tell me what it was looking at. I had to Tab around blindly to get to a usable control, and even then, VO couldn't tell me where it was or in what context.

I couldn't actually create a new project because the "Finish" button, when creating a project, didn't seem to do anything, either through VO or using the mouse pointer directly. The button was lit up and coloured as though it were selectable, it just didn't do anything. So I couldn't actually play with the IDE itself, but I knew I was done with it.

The design looks and feels like Windows in the late 90s/early 00s, from the layout of various windows to those weird tear-off sidebar things. I especially despised the tiny icons that all practically looked the same, conceptually blurred together, and I couldn't find a clear way to make them bigger. VO saw each draggable toolbar as separate, making the toolbar at the top unnecessarily difficulty to navigate. Then those same icons infiltrated the global menus, making those a mess to wade through.

I'm a great believer that there is absolutely nothing stopping cross-platform desktop software being a first class citizen on, at the very least, the three main players: Windows, macOS, and Linux. Sadly, Eclipse, like most Java software, thinks it can get away with the last common denominator stuff and force it on other systems. It just makes for a rather unpleasant time, whether VO is on or not. Native widgets don't make up for non-native design patterns.

Sorry for the novel!

As to NVDA, I expect NVDA uses some heuristics to figure out how to read out all the myriad types of interfaces there are on Windows. I remember one app for vision impaired people, I can't remember it's name because I wound up passing on actually buying it, that basically constantly scanned what was on screen and made informed guesses. I'd say VoiceOver probably relies more on well-made apps conforming to system guidelines; if so, it's somewhere between naïve and brilliant, because I personally favour a system where accessibility is a first-class citizen, not an afterthought for which we need to call upon the powers of magic to figure things out.

[tokyodude]

I find native apps frustrating that they won't let me select what I want, only what they want to allow me to select, where as in a web page I can generally select whatever I want.

[zapzupnz]

This is true for web pages, but not necessarily true for native web apps (like Discord, VS Code, etc.) where certain UI elements are just as inaccessible as in native Cocoa apps; sometimes you can get to them by enabling a web inspector (if it's possible), but not always.

Depends on the app, I find, and how well it's made.