Is this still the case that you don't accessibility (on iOS) if you don't use native widgets?

Isn't there a way to "publish", "expose" say text and other information to the system? I believe for example Windows has this, and Qt on the desktop can use it (although there were still complaints, that some really popular brand of braille reader was not working).

Simply curious, as long time ago I was heavy proponent of native only widgeting systems (like wxWidgets), but lately in favour of self-drawn one, but imitating the interface (like Qt).

It might be more challenging without native widgets but it looks like it's still going to be implemented:

"Flutter has basic support for accessibility on iOS and Android, though this feature is a work in progress."

https://flutter.io/faq/#how-do-i-do-internationalization-i18...

https://flutter.io/widgets/accessibility/

I don't think this is possible on iOS. I don't think it is currently possible to achieve VoiceOver support, for example.

(Disclaimer: I work on Flutter.) As skybrian says, accessibility support is work-in-progress. But if you try an existing Flutter app (e.g. the official Hamilton App) you'll note that most aspects of the app are accessible to VoiceOver, just not quite everything yet. We're actively working on improving our iOS and Android accessibility integration.

If you wrap native widgets it is.

I don't think this is what they are doing, which is what I meant. How are Flutter widgets drawn on the screen?

(disclaimer: I work on Flutter.) Flutter uses its own renderer based on Skia. Flutter essentially asks the OS for an surface to draw onto, and then Flutter draws all the pixels through Skia.

In such case, this is what I feared; I don’t think it is possible to implement proper VoiceOver support with the current public API.

You should file bug reports with Apple to enable that.

If you write a native app programatically, you replace all your localizable strings with NSLocalizedString(@"string to translate", @"message for translator") - or similar in Swift. There's also support for localizing strings that you supply in your plist config files, which are strings for things like telling a user why you want a certain permission.

If you use a lot of Interface Builder (IB), then your localization support stems from all the basic UIKit widgets having support for localization built into IB, and in that case you'll end up building custom components on top of your UIKit blocks, and localizing via IB.

One of the views in an app I work on (a Settings view) also uses some plists to generate the table, so we end up having a bit of code to generate the NSLocalizedStrings for the stuff that's not actually in the source code.

Accessibility is not localization.