[zapzupnz]

Native widgets don't just mean "look". They can also mean "feel". This is particularly true on macOS.

On macOS, I expect certain widgets in order to accomplish certain tasks. I expect that they will respond to mouseover and button presses in a certain way. I expect to be able to use certain key combinations to cause certain widgets to do certain things, I expect keyboard combinations to be able to be redefined in System Preferences.

On the accessibility front, I expect VoiceOver to be able to read what's on screen, I expect it to be able to tell me what a widget's behaviour will be, I expect to be able to get back to where I was using a standard key combo, I expect images to respect colour inversion settings, I expect text to scale according to the system's Dynamic Type settings.

When it comes to handling text; I expect fonts to have the system's native rendering; I expect that Unicode support is complete, I expect macOS' emoji picker to show up; I expect system-wide text replacements, smart quotes, and orthography checking to work as expected, I expect selectable text to show a list of system-wide Services in the context menu, I expect all text to be draggable and handled correctly by the receiver of the drag action.

There are plenty of other things that I can't think of, but this list could get quite long. Suffice to say, Apple put a lot of default behaviours into Cocoa, and apps that (A) don't use Cocoa, or (B) only use Cocoa for drawing but not inheriting behaviours, they don't just look a bit off, they feel _wrong_.

I think we may be immune to this to some extent on mobile, and Windows users haven't known anything other than complete inconsistency, even with Microsoft's own built-in interfaces. But for some of us, if the interface feels wrong, the app goes straight into the Trash.

[saagarjha]

Cocoa Touch, while being slightly simpler and less arcane than Cocoa, still has a lot of semi-hidden behaviors that are nonobvious to cross-platform UI framework implementers.

[zapzupnz]

I notice this most when playing games and I can't get context menus to show up with long presses.

[tokyodude]

I'm trying to find an example of this "long press shows context menu". Tried long pressing a link in Safari Mac no context menu appears. Ctrl-Click brings up context menu. Tried long pressing a shortcut, no context menu but ctrl-click brings up context menu. Tried selecting and long clicking a file in Finder. No context menu appears but ctrl-click brings up context menu. Tried selecting some text in TextEdit and long pressing, No luck. Ctrl-Click brings up context menu. Tried long pressing a tab in the ruler, same issue. It seems like even for Apple this isn't much of a standard.

[zapzupnz]

The person to whom I was replying was talking about Cocoa Touch, so this was about iOS, not macOS. If it interests anybody, the specific example was Pokémon Go's text fields which _do_ respond to Cmd-V, but I can't long press to get Copy|Paste to show up.

[tom_]

The takeaway here is that each OS trains you in its own way to look down at all those morons using one of the other ones.

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

[phs318u]

While the intention of the design may not be what you describe, one of the consequences often is.