I was hoping to see better HTML rendering. Using a single canvas to render web apps was my one turn off. Flutter is the right choice for many apps, but not for apps primarily accessed over the Web.
It is not production ready for web and I don't have much hope it ever will be. I love it for mobile, even desktop apps. But I feel they chose the wrong direction at the beginning for web and it's just trying to dig back out of that hole since then.
For desktop and mobile, Flutter renders over OpenGL, why do they need to embed chrome ?
The websites that are exported from Flutter use the HTML canvas (used for games, animation, etc) instead of trying to generate HTML. This means accessibility and SEO are on existent for those sites. GP is complaining about this.
Although it may render faster, it comes at a cost, as it completely circumvents what browsers are good at.
Flutter is basically just painting pixels on a canvas manually, meaning no CSS, no text selection, no text wrapping, no responsive elements, no elements without JS enabled. Many accessibility tools rely on CSS and text in HTML in order to work too.
It's a huge trade-off to make, and something to be aware of.
FYI there is a SelectableText widget included in Flutter[1] but the developer has to explicitly make text selectable just like iOS and just like Android apps. Desktop is a different story... many text selection paradigms that I'm familiar with on desktop (like double-click and hold and drag to select whole words) simply don't work right. It's not a great experience, but neither is the vast majority of non-Flutter mobile apps when it comes to selecting text too.
wrt accessibility, Flutter does actually generate elements with aria attributes for screenreaders to consume[2]. You're right that the canvas is inaccessible, which is why the aria labels have to be generated adjacent to that.
We're using Flutter for mobile development at my workplace.
This right here should tell you why you shouldn't use Flutter for Web. The Web is pretty great for accessibility out of the box until us devs mess it up, we shouldn't use a technology that needs to completely build it from scratch to get it to work.
I'm going off of memory here but I think it's approximately correct. They were playing around with the idea for a while of creating "virtual trees" to handle accessibility and ultimately had to abandon it for privacy reasons because you would be able to imply that anyone who was using the virtual tree was differently abled and that was a whole can of worms that couldn't be resolved.
I believe the spec you link is a future proposal at the moment. And I trust a consortium of folks from a variety of browser vendors along with folks from other interests over a single product, when it comes to trying to figure out a better way to make things more accessible. And maybe Flutter can just use AOM in the future when it's available in browsers.
As of Feb, 2022:
> While still in draft form within the Web Incubator Community Group, the Accessibility Object Model (AOM) intends to incubate APIs that make it easier to express accessibility semantics and potentially allow read access to the computed accessibility tree.
Are there declarative and performant ways to synchronize a canvas with a DOM tree? Maybe the answer here is obvious but this seems like quite a bit of overhead, both for developers and the browser.
Do they need to be synchronized? I can’t imagine that a screen reader would be sensitive to millisecond-level discrepancies between canvas updates and DOM updates.
I’m not concerned about the delay between updates, it’s the correctness of the DOM and the canvas and managing interactions between the two. I might be misunderstanding the problem (or lack thereof) because I haven’t dealt with accessibility and canvas.
When it comes down to it, I have no idea how you’d indicate something is selected in the canvas and have a screen reader correctly read out the current selection from the DOM. Would DOM events communicate to the canvas how to modify state, functions to call, etc?
How would you manage focus between the canvas element and the rest of the DOM? Apologies if I’m not making sense; maybe there’s a well known pattern people use for things like this.
My understanding of accessibility relies heavily on the DOM behaving as a single document, and the idea of a sort of meta-document within it which coordinates pieces of the documents seems very complex and hard to get right.
Because it destorys native browser features. For example find-in-page, hove to see where a link goes. Right click a link to bookmark, open in private window or copy the URL. If the page has anchors I can get a link to them. If I save or print the page it is an image rather than text (with all of the above features).
Some of these can be reimplemented easily, some of them with effort, but some just aren't possible. Plus the exact behaviours depend on what browser you are using, so you can't reimplement them because you don't know how the user's browser behaves.
For games or image editors this is probably fine. But for most apps this is a huge depredation in usability.
no canvas are slower for UIs. The difference is between immediate vs retained mode rendering, and the later is order of magnitude more energy efficiency and is more performant, for well behaving not chaotically changing content.
