We actually use plain standard HTML and ARIA attributes for accessibility. If you don't see them, try enabling a screen reader (e.g. TalkBack on Android, VoiceOver on iOS/macOS), then you'll be able to enable accessibility in the app. If you are having problems with a11y, please file a github issue. A11y is very important to us.
How about stuff like being able to select text in the UI? I tried a couple apps in https://gallery.flutter.dev/#/ and none of the text was selectable like in web and desktop interfaces
Flutter's Text widget (which is generally the default for most devs when displaying text) doesn't allow for text selection. There's a SelectableText widget that does, though:
While Flutter makes text selection an explicit choice for developers, Text vs SelectableText, for some reason Text ended up being most used. This is likely because SelectableText came after Text and because of Flutter's mobile background. Most mobile apps use non-selectable text, and so this ended up on Flutter developers' default path.
I personally expect this trend to continue, as in most desktop native apps text is not selectable either. In fact, in many web apps (those that are really _apps_, not just static web-sites) there's lots on non-selectable text. Case in point, I just checked Gmail's landing screen, and I failed to find a single piece of selectable text.
Huh I never noticed that with gmail. I'm guessing it's because if I wanted to copy some sort of text, you could do it with the email detail page. And most text is selectable there, from the email name, actual emails, document content, etc. In mobile devices, text selection is such a pain so the desire to do it is less.
Does selectable text have a performance penalty? In iOS UILabel is far faster to render than UITextView, but only UITextView is selectable. I wouldn't mind if many of my UILabels were selectable, but I'm forced by performance constraints to not let it happen.
Maybe put forward making SelectableText the default and renamed to Text and Text is renamed to UnselectableText and becomes the non default if there isn't a perf penalty? It would need an automatic migrator for that to happen although.
Proper links and mapping of navigation to browser history are also important for any content-focused webapp. Keyboard navigation is incomplete too (some elements like dropdowns).
I hear you. There's a link widget coming, multiple browser history models (we've only supported URL fragments, but are adding pushState, and custom URL strategies, as well as navigation API improvements). Keyboard navigation is being actively improved. Bug reports are always welcome: https://github.com/flutter/flutter/issues/new/choose
We actually use plain standard HTML and ARIA attributes for accessibility. If you don't see them, try enabling a screen reader (e.g. TalkBack on Android, VoiceOver on iOS/macOS), then you'll be able to enable accessibility in the app. If you are having problems with a11y, please file a github issue. A11y is very important to us.