Live data from Hacker News

WebAssembly Studio

webassembly.studio

71–80 of 231 posts

Re: WebAssembly Studio

#71
post #44

I love dark mode as much as the next guy but only when it's done right. This is borderline unuseable for some people [1]. An example of dark mode done right is the default theme for monkeytype [2]. I know it's a default theme but a light alternative would be nice. [1]: https://jessicaotis.com/academia/never-use-white-text-on-a-b... [2]: https://monkeytype.com/

Yes I can't look at it. It should be interesting though so I've bookmarked it to come back to. I'll use a browser plugin to 'fix' it if necessary.

Re: WebAssembly Studio

#72

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…

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.

Re: WebAssembly Studio

#73

Question for anyone with real WASM experience: what are your top recommended entry points / reference materials? AssemblyScript seems pretty approachable at 1st glance...

I've played around with Haskell via the Asteruis project : https://github.com/tweag/asterius

Also emscripten of course, for C/C++.

Re: WebAssembly Studio

#74

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,…

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…

> > The buttons are clickable divs, not actual HTML buttons

> It'd certainly be nice if everything just automagically worked about accessible UI but we're not there yet

OP's suggestion is that the author should have used native HTML , a simple solution that has worked since the beginning.

But you're right that it's not so elegant in reality:

You must remember to add type="button" attribute, otherwise clicking it could trigger page reload accidentally.

Most browsers still force to retain its default display property. Within flowing text, it can never break naturally onto the next line, whereas an link can.

It also can't be a flex or grid container in certain browsers, so you often need an inner element for proper spacing/positioning.

Note that the inner element would need to be a not a because can only contain phrasing elements.

Re: WebAssembly Studio

#75
post #13

It would be nice if there was a no-javascript fallback - at least a message saying "This site only works with javascript enabled." If you have noscript, this site is completely blank until you enable a couple of things and reload.

Perhaps a missing browser feature?

"You loaded a page with JS but you also disabled JS execution, so it probably won't work"

Re: WebAssembly Studio

#76

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…

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.

[deleted]

Re: WebAssembly Studio

#77

Earlier quoted context omitted.

Users with accessibility needs deserve to be able to use software as much as any of the rest of us do, and we should pride ourselves in making time to address their needs. Try reading your comment from the perspective of someone who is unable to use this software because of the choices you've made. Someday, perhaps sooner than you think, you might find yourself in their shoes. In this case, mwcampbell refers to a spe…

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.

Re: WebAssembly Studio

#78

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,…

I read your comment as unnecessarily abrasive, self-entitled almost.

> "It breaks my heart that when this project was started in 2017, some 20 years after web accessibility advocacy had started in earnest, the developer was still uninformed enough about accessibility that they would create a custom button component with no ARIA support."

You're assuming ignorance and malice, when in all actuality this most likely comes down to priorities, and a painful lack of clear standards and tooling. By all means - please submit a patch with what you deem is the right solution here, instead of just expecting things get done your way on day one.

> "The buttons are clickable divs, not actual HTML buttons"

What's an "actual" HTML button we can all safely use to replace simple divs (which are just about the only way to get content to show up and behave uniformely across browsers and platforms, using as little js/css hacks as possible)?

Re: WebAssembly Studio

#79

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,…

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.
Post reply on HN