It probably would have reduced my developer effort considerably compared to basically every other option that made it to my short list, but I can't in good conscience build something that isn't accessible.
Did you actually try it?
This is making a mockery of accessibility.
It's the equivalent of having a company that actively discriminates against everyone not passing a internally developed test to check whether you are a "neurotypical" and then respond to criticism by pointing at the wheelchair ramp you installed on one of your entrances.
If I can't copy paste words from your websites to put them into a translator, if I can only use your website when I use one of the two corporate-affiliate-selected screen readers (not even platform-agnostic ones), when I can't look at your website from anything that does not have 4+ cores and a 4G or better connection...saying accessiblity is a "first class citizen" or even citizen at all is laughable at best.
Regarding performance: Chrome uses Skia to render the DOM, why do you think rendering Flutter, also based on Skia, should be so much worse?
Meaning that, in a slate of options where one of them can definitely do something you need, and another one where the official story seems to be ¯\_(ツ)_/¯ and the examples you've seen seem to indicate that it's at least something you need to go out of your way to accomplish, there really isn't any injustice in deciding to expend no further mental energy on the latter.
That said, if you want spend your own time digging in and finding out, be my guest.
Nothing else is production-ready and can run on the web, iOS, Android and desktop OSs (Linux, Windows, MacOS).
It's not competing with pure web frameworks. For this reason, yes, I think that if you're going to criticize it, you absolutely need to know what you're talking about... if Flutter claims it can handle accessibility, it's on you to prove it can't if you make this argument so eloquently on the Internet without actually knowing it.
BTW if you know of any other good UI Toolkits that really can run anywhere like Flutter, using the same code base, please let me know.
For example, that page you link is specific to iOS and Android targets. Nary a mention of what to do when you're targeting the Web. But it's also, at least as of when I did my comparison, explicitly not supported on at least some desktop targets.
It's the equivalent of having a company that actively discriminates against everyone not passing a internally developed test to check whether you are a "neurotypical" and then respond to criticism by pointing at the wheelchair ramp you installed on one of your entrances.
If I can't copy paste words from your websites to put them into a translator, if I can only use your website when I use one of the two corporate-affiliate-selected screen readers (not even platform-agnostic ones), when I can't look at your website from anything that does not have 4+ cores and a 4G or better connection...saying accessiblity is a "first class citizen" or even citizen at all is laughable at best.
That is attacked through very different means. For example, FB being free and ad funded addresses that issue; but this is a business model and not a technological standard. Society subsidizing technology is another possibility. But these very serious issues of access and the solutions to negotiate with them are very different from purely technical solutions to access.
If your website is unreadable in view-source:, it's probably inaccessible in some way. It's not hard to make an accessible website. If it's hard to make that accessible website look the way you want? Tough luck; hire a competent web designer, or scale back your artistic vision, because you sure ain't sacrificing the ability for people to actually use your website for some pretty colours, are you now?
For example, suppose the entire purpose of a certain office application is to draw some clever visualisation that helps the office workers to understand complex relationships in their business data. Maybe that presentation style has been chosen based on years of experience and saves a lot of time and avoids a lot of mistakes compared to a simple text report or table of figures. However, maybe it also doesn't work for someone whose vision is too limited to usefully see or interact with the visualisation.
Perhaps you could present the same data and relationships in a different way, a format that would be more amenable to sound- or touch-based interfaces for those with severely limited or no vision. In reality, that might mean writing a second entirely separate application, one that might cost more than the original to implement and support, for an audience that will usually be very small and often empty.
So where should the line be drawn? In an ideal world we want to be as inclusive as possible regardless of anyone's individual limitations, but we also want to provide the most effective presentation possible to those who don't have the same limitations. In general doing both might be prohibitively expensive, so how do you make realistic, ethical decisions in this space, and given that every software application is different, how do you codify the standards you want to make mandatory for the accessibility reasons?
Cannot read property 'match' of undefined
TypeError: Cannot read property 'match' of undefined
at /var/app/current/routes/avs.js:44:29
at Layer.handle [as handle_request] (/var/app/current/node_modules/express/lib/router/layer.js:95:5)
at next (/var/app/current/node_modules/express/lib/router/route.js:137:13)
at Route.dispatch (/var/app/current/node_modules/express/lib/router/route.js:112:3)
at Layer.handle [as handle_request] (/var/app/current/node_modules/express/lib/router/layer.js:95:5)
at /var/app/current/node_modules/express/lib/router/index.js:281:22
at param (/var/app/current/node_modules/express/lib/router/index.js:354:14)
at param (/var/app/current/node_modules/express/lib/router/index.js:365:14)
at param (/var/app/current/node_modules/express/lib/router/index.js:365:14)
at Function.process_params (/var/app/current/node_modules/express/lib/router/index.js:410:3)