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.
You can't even select and copy text. And canvas is inaccessible to screen readers