91–100 of 231 posts
Something similar but also totally different is https://makepad.nl/ - a graphics programming IDE in Rust, for Rust, targeting the browser. It's a totally different use case but there's some similarities, somehow, anyway. Unlike this app, its actually all WASM and the author frequently tweets about how he feels more productive building a web UI in Rust than he would HTML+CSS+JS. And you can say what you want, the thin…
The "Create New Project" dialog has serious accessibility problems when used with a screen reader. The buttons are clickable divs, not actual HTML buttons or even marked up with proper ARIA. I haven't yet ventured any further into the app. Given that the app is a WebAssembly development environment, my first guess was that it was built in WebAssembly itself, with a custom UI framework. But in fact, it's plain React,…
Earlier quoted context omitted.
Why assume ignorance/difficulty when the reality is not everyone is going to focus on adding/maintaining accessibility when they haven't even built out their beta MIT licensed side project? It'd certainly be nice if everything just automagically worked about accessible UI but we're not there yet (getting anything to automagically work in UI is a pain still). As far as what we can do about it I suppose outside of some…
What does being MIT licensed have to do with it? And please, don't anyone dare chime in with the the standard "if people want a feature in open source they can 'simply' implement it themselves". UI technologies that don't include accessibility are simply not good enough. It's not like accessible options don't exist.
It's a non commercial non government project.
> And please, don't anyone dare chime in with the the standard "if people want a feature in open source they can 'simply' implement it themselves".
Already talked about it in the parent comment, would be interesting if you could respond to that instead of asking nobody mention it.
> UI technologies that don't include accessibility are simply not good enough.
Agreed, most software is not good enough. Especially beta versions of personal projects.
> It's not like accessible options don't exist.
It's not enough for something to exist it has to be pervasive and perfect to not be caught in a project task list for something like this. This point is the topic of conversation.
Earlier quoted context omitted.
I'm also intrigued by the possibilities of WebAssembly. However I also have a nagging feeling "didn't we already do this with Java, 20 years ago?". Wondering what's different this time, or is this just a MySpace vs Facebook second-times-the-charm thing.
The difference is that wasm is designed to be sandboxed, instead of the JVM which was designed to normalize disparate computing environments. In practice, this entails a lot of work to create runtimes to do anything interesting in wasm, but the behavior is secure by default (ignoring side-channel attacks, of course). Java applets run in a sandbox by default, of course, but the JRE itself has unmitigated access to the…
As does the browser in which WebAssembly executes.
> Users can also be tricked to trust malicious applets
But the ability of applets to be trusted could have been eliminated entirely. To rewrite OP's question, then:
"If we had entirely gotten rid of trusted applets, couldn't we already do this with Java, 20 years ago?"
Of course, we didn't get rid of them, but that's still a valid question vs. inventing another technology.
Earlier quoted context omitted.
I agree that if we make something we intend for others to use it should aim to be accessible to others. Nobody here is saying others shouldn't be able to use software the problem is software is never complete and for a project like this getting the thing working may reasonably happen before you add ARIA attributes without the cause being enmity to others. I might be missing something, how would it have been easier to…
The clickable divs should be focusable and have the aria button role. ...
Earlier quoted context omitted.
Exactly this. Yes, accessibility is very important, but as of right now, it takes non-zero effort to implement correctly. So you must balance that with other priorities depending on the goals of the project.
The goals of the project includes "custom buttons"? There's so much functionality that you get for free/low effort if you don't feel the need to customize everything to the nines.
• It has to have lots of custom animations, because animations are fun.
• It has to work well in weird text-based browsers like Links, because being able to load my site up in those feels cool.
• It has to support Safari 6, because that's the last version of Safari that works in Snow Leopard.
If it's a non-commercial project, the goals can be whatever the fuck the author wants them to be.
Earlier quoted context omitted.
I agree that if we make something we intend for others to use it should aim to be accessible to others. Nobody here is saying others shouldn't be able to use software the problem is software is never complete and for a project like this getting the thing working may reasonably happen before you add ARIA attributes without the cause being enmity to others. I might be missing something, how would it have been easier to…
They could have just used off-the-shelf components for the first iteration.
Would it have been accessible though, sure. But I'm going to assume that the developer didn't spin a wheel and decide to add React to the project rather it was intentionally chosen for some reason. Similarly in their React button version they could have added ARIA attributes. The problem statement was never "is there a way it could have been made accessible" it's that there isn't going to be a fullproof automagical way to make it accessible without having to do additional work in the project be it styling the default button or changing it's handlers or adding accessibility to a custom button.
i.e. it's not a matter of technical exercise for how it could have been accessible it's being realistic about why it wasn't.
Jokes about the [Birth and Death of JavaScript]( https://www.destroyallsoftware.com/talks/the-birth-and-death... ) aside, I love the concept of WASM and that we're making the web a more robust compile target. One of the big limitations in my mind is that I still don't know of that many people using it in production at scale. Is there a list, or well known set of examples (other than Figma), who are using WASM in prod…
https://www.youtube.com/results?search_query=gary+bernhardt+...
Earlier quoted context omitted.
Why assume ignorance/difficulty when the reality is not everyone is going to focus on adding/maintaining accessibility when they haven't even built out their beta MIT licensed side project? It'd certainly be nice if everything just automagically worked about accessible UI but we're not there yet (getting anything to automagically work in UI is a pain still). As far as what we can do about it I suppose outside of some…
How hard is it to just use a damn For a button on a web page? Basic HTML already works perfectly in a screen reader with no effort. It requires effort to screw it up.
The tl;dr is it's not about there being a way it could have been accessible it's that there was no out of the box answer that both did what the project needed and what was needed to have the button be accessible. If you are here to point out there is a way it could have been done well of course, so could everything else on every backlog of every open source project but things get taken off of the backlog by people planning work and putting the time in to do them not by people mentioning there are easy ways it could be done hence why this wasn't done (and also why this/any piece of software isn't perfect as everyone would like).
Seeing gulp being used in the examples for the build step is strange... I wonder why it was chosen. Nothing wrong with it per se but gives me flashbacks to the horrors of my past exposure to it as an inexperienced webdev.
Gulp is still widely used for more general build-related tasks like moving files around but sometimes you have a more complex build pipeline where you need to invoke bundlers/babel/etc via Gulp.
The promises of gulp (streams) fell short pretty quickly and we were just left with verbose spaghetti code that was no better than just a bash script. I went into gulp head first and honestly I’m glad that Webpack can deal with most of what I did back then, especially when paired with other reasonable CLI tools.