It's unfortunate that the web mode uses a canvas and won't work with native browser accessibility stuff. That was the show stopper for me last time I've tried it.
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.
https://api.flutter.dev/flutter/material/SelectableText-clas...
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.
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.
For example, pressing "f" with Vimium should enumerate things that can be clicked(think anchor elements and button elements) but it enumerates nothing on https://gallery.flutter.dev/#/. This is a pretty good proxy for accessibility too i.e. things that can be clicked look like they can be to the machine. A quick document.querySelectorAll('a') and document.querySelectorAll('button') in the console verifies that there are no such elements.
Another one, basic browser features like backswipe on the trackpad to go back just doens't work.
Custom user agent stylesheets is another accessibility/power user feature that will not work
You cannot select any text as far as I can tell
Reader mode doesn’t work, not even on the news demo which is a prime example of where it should work
You cannot copy or preview link URLs
You cannot copy image URLs
Navigating by landmarks(such as headings) probably also doesn’t work(I haven’t tried this yet)
Vimium is an interesting use-case. I've never heard of this extension. We have in the past enabled accessibility DOM all the time, but due to performance concerns changed it to be opt-in. If you use the standard screen reader (e.g. VoiceOver on iOS/macOS, TalkBack on Android, etc) you will get a way to enable accessibility DOM with ARIA tags, etc. Perhaps we should reconsider it (may need to optimize it a little though). I'd be curious whether Vimium works when accessibility is enabled.
Some features you list we either should support or already do: backswipe (good feature request), text selection (use the SelectableText widget), links (in the works), image URLs (good feature request). Not sure what navigating by landmarks is, but perhaps something we could support too.
Stylesheets are a non-goal. We do allow embedding plain HTML/CSS (called "platform view"), where you can use CSS, but Flutter's own widget system uses its own styling/theming.
Reader mode makes sense for "documents" (think news sites, wiki, documentation, etc), but it's unlikely to work out of the box in dynamic apps (think email, calendar, maps, graphics editor, etc) which is the kind of apps Flutter is going for. There's a similar issue with Ctrl + F (Cmd + F) to find text on page, which is not helpful in dynamic apps. Dynamic apps are better off implementing their own app-specific "reader mode" and "search bar", one that takes the nuances of the app into account. But never say never, maybe that's doable too, perhaps using our accessibility tree, at least for static document use-cases.