https://gallery.flutter.dev/#/
and marvel at the impossible to select text, one of the many affordances violently excised here.
If it wasn't still incredibly slow even on a cutting-edge Zen3, Nvidia 3070 system they might almost be on to something here.
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)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?
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.
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.
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?
Leading to questions like this: http://forum.amiga.org/index.php?topic=10580.0
Here's me almost hoping that ADA lawyers will have many field days with this tech. Edit: since this time there is no good excuse for it.
Progress
... along with tracking exactly what you copied, when, where you hovered your mouse, inserting all sorts of features into your copied piece of “plain text”
... along with the ability to force-turn off copying from server side whenever it benefits them.
You WILL use ChromeOS (by another name) and you WILL like it
Currently it’s pretty easy to get around such blocks. Compare with how hard it is to get around modern, proper DRM.
I have faith this implementation will be modern and proper, as the fate of the ad industry and those who rely on it, rely on it.
I am not really sure about Flutter for web though.
If the Flutter dev experience is good enough, this will eat traditional web apps slowly. In a way, the web was designed for this sort of scenario: a delivery mechanism agnostic of the client implementation. We've gone from pushing server-generated HTML to megabytes of JS + SPAs, and now a WASM/Canvas hybrid seems inevitable.
It all comes down to how well these perform on mobile devices, what the dev experience is like, and how the end product feels. There's still a lot up in the air, but, I'm honestly impressed with the progress shown by Flutter here. There's still a host of considerations unaddressed (including accessibility) that I hope they have an approach for.
What has flutter to offer that a regular webapp lacks? (not performance, it seems)
If Dart/Flutter is good enough for all of those platforms, that is quite the value proposition.
> What has flutter to offer that a regular webapp lacks?
Google branding, novelty, more sane dev UX. I'm not saying those are good reasons to choose it, I'm just extrapolating from how the industry works.
Let's be honest: end users basically just put up with whatever devs release at this point. It doesn't matter if the end product murders battery life, doesn't fit the target platform, and steals their data. It's not like switching to some less-than-web-native framework is somehow a bridge too far for end users.
But who are we kidding, the web is javascript all the way down now.
For me the balance is still the same. Fine for highly interactive things such as games. For everything else, ugh...
Seems like it's fast (on my machine at least), can select text and Ctrl+F works. I totally understand the urge to complain and doom say, but could we at least stick to the example at hand? I'm sure if you went through this doc you'd find things to complain about. That would be more relevant to the discussion.
I didn't spend more than a few seconds on it, but those were the features I immediately noticed. This is going to be a painful transition for us since she uses both of those a great deal with her schoolwork. Since the doc was read-only, I couldn't test IME/XCompose - hopefully those work at least.
But I'm not sure how they could integrate with browser spellcheck without basically going back to a less canvas-y approach. Invisible text areas surely would have layout problems aligning with the rendered font. But, I guess we'll see. I'm guessing Linux users are not a major factor in their decisions though. Firefox users probably even less so.
Yes, they actually built an email client from which you cannot copy text: https://gallery.flutter.dev/#/reply
The only thing I saw that didn'r run smoothly on my weak phone is the flutter plasma demo[0], but it runs without any tearing on the laptop.
I have two stupid flutter apps that are canvas only - https://malkia.github.io/game_of_life/ and https://malkia.github.io/tictactoe (but haven't rebuilt them with latest & greatest)
Which clearly says all I need to know about it :-/
EDIT: to be fair, it runs quite smoothly on Safari and Google Chrome... only Firefox seems to have trouble with Flutter on the Web for some reason.