Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly Studio

webassembly.studio

Post reply on HN
Print view View original

131–140 of 231 posts

Re: WebAssembly Studio

#131

Post by clickness »

curryst wrote: post #122
joshjhargreaves wrote: post #87

Earlier quoted context omitted.

It's almost as if some people get off on the feeling of self-importance they get for 'calling people out' in this manner- the neckbeards of accessibility. In an ideal world, accessibility would come for free - but unfortunately it does not. Yes I would argue that morally projects should do their best to support it - but even at well established companies it takes significant resources to maintain accessibility. Yes i…

It's an intractable problem; most people believe software should be accessible to people with different needs, and most people also believe that other people shouldn't be able to force you to do work for free. Which one you decide on seems like a value judgement to me. Is it fair that instead of shipping that feature you really want this month, you have to do accessibility features? I don't think the answer is black…

> "FWIW, accessibility seems hard."

Exactly.

Changing to , passing your website through an "accessibility validator" or adding an accessibility toolbar don't guarantee your website is actually usable on a screen reader (as an example).

Getting accessibility right takes non-trivial effort.

Re: WebAssembly Studio

#132

Post by mwcampbell »

cassetti wrote: post #124
mwcampbell wrote: post #10

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

> It breaks my heart This is all a little dramatic, no? It's a cool app that can be easily updated to fix button accessibility.

Yes, on second thought, that one sentence was probably melodramatic.

Re: WebAssembly Studio

#133

Post by chrismorgan »

pickpuck wrote: post #74
zamadatix wrote: post #48

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…

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

I quibble over a few of your points:

(a) type="button" only does anything if the button is form-associated—otherwise it’s the default. And even then, if your button within a form is semantically submit buttons (as the Create button here is), the semantically-best technique is instead to leave the button as a submit button, and instead of using a click handler on the button, to use a submit handler on the form and do event.preventDefault() within it.

(b) That buttons don’t wrap externally is a feature, not a bug. Links should wrap. Buttons should not. The point here is that it is a button, so it should use , and this is just one of the reasons why.

(c) not supporting `display: flex` was Firefox-specific and fixed almost four years ago in Firefox 52. I believe the last fiddly alignment corner cases were fixed over two years ago also. So you can safely forget about that limitation now.

(d) You shouldn’t want to put a div inside a button, any sort of button (whether or any other technique). That’s not what buttons are.

Re: WebAssembly Studio

#134

Post by yjftsjthsd-h »

simonh wrote: post #86
zamadatix wrote: post #48

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.

> 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".

Indeed, how dare anyone call you out on demanding that others invest time and effort that you won't.

Re: WebAssembly Studio

#135

Post by paulgb »

Yuioup wrote: post #123
pjmlp wrote: post #5

Earlier quoted context omitted.

Autodesk. https://www.infoq.com/presentations/autocad-webassembly/ https://blogs.autodesk.com/autocad/autocad-web-app-google-io... https://forge.autodesk.com/blog/load-encrypted-model-data-we... BabylonJS plugins https://babylonjs.medium.com/marker-tracking-in-babylon-js-c... Blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor Uno https://platform.uno/

The 90s called. They want their RAD tools back.

Let’s get them on the phone and negotiate a joint-custody deal, then, because I feel like RAD has only gone downhill since then.

Thinking back to how easy it is to open up VB5, drag-and-drop a UI, and ship an .exe that anyone could run (yes, because of MS’s OS monopoly, but still), the current mess required to build a similarly complex app for the web feels like a serious regression.

Re: WebAssembly Studio

#136

Post by sbarre »

Yuioup wrote: post #123
pjmlp wrote: post #5

Earlier quoted context omitted.

Autodesk. https://www.infoq.com/presentations/autocad-webassembly/ https://blogs.autodesk.com/autocad/autocad-web-app-google-io... https://forge.autodesk.com/blog/load-encrypted-model-data-we... BabylonJS plugins https://babylonjs.medium.com/marker-tracking-in-babylon-js-c... Blazor https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor Uno https://platform.uno/

The 90s called. They want their RAD tools back.

Hi 90s, this is 2020... OP can't take your call right now because they are busy building low-code environments to help companies keep their dozens of bootcamp hires productively building in-house line-of-business tools that will be a nightmare of maintenance and technical debt in 3 years.

Did you want to leave a message? Perhaps some kind of cautionary tale?

Re: WebAssembly Studio

#137

Post by chrismorgan »

xingyzt wrote: post #81
zamadatix wrote: post #63

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. ...

This is necessary but insufficient. If you use role=button, it needs to behave like a button, which means that Space and Enter must also activate it.

Things to read:

https://www.w3.org/TR/wai-aria-practices/#read_me_first

https://www.w3.org/TR/wai-aria-practices/#button

Re: WebAssembly Studio

#138

Post by yjftsjthsd-h »

dboreham wrote: post #75
blunte wrote: 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"

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

Plenty of websites embed JS but work fine with some (or sometimes all) of it disabled.

Re: WebAssembly Studio

#139

Post by fiddlerwoaroof »

corytheboyd wrote: post #113
ddevault wrote: post #59

Earlier quoted context omitted.

You should fix this attitude, becuase it's making your applications worse. The browser is the best at doing the things it does, and any control that you implement yourself is going to be worse. If the browser can do something for you, you ought to let it do that for you. If you insist on writing your own controls, its behavior will differ from how the browser's own UI works in subtle ways, repeated indefinitely for e…

I didn’t downvote because I can agree to a certain extent. Are you suggesting a completely unstyled web or something? Maybe if you fleshed out that idea you would be met with less criticism. There is a good lesson here though, native browser controls should ALWAYS be your first consideration when building UI for the web. Try everything under the sun to stick as close to these as possible before you give up. You will…

Dropdowns are frustrating because the select/option is only really good for simple cases and browsers block restyling: as soon as you get a requirement like “Dropdown with multiselect”, you have to rewrite the whole thing: and, for visual consistency, this usually means rewriting all the dropdowns.

Re: WebAssembly Studio

#140

Post by chrismorgan »

ddevault wrote: post #59
bavell wrote: post #24

Earlier quoted context omitted.

I'm guilty of this more often than I should be. I think the reason I sometimes reach for divs over buttons or other semantic elements is because I've been burned by default browser behavior treating them special when I just want a dumb box with a dumb click handler - no default styling that I need to override, no need to call .preventDefault(), no need to worry about the matrix of OS+browser+device that each treats a…

You should fix this attitude, becuase it's making your applications worse. The browser is the best at doing the things it does, and any control that you implement yourself is going to be worse. If the browser can do something for you, you ought to let it do that for you. If you insist on writing your own controls, its behavior will differ from how the browser's own UI works in subtle ways, repeated indefinitely for e…

To those disagreeing with Drew here: he’s expressing it very bluntly, but what he’s saying is absolutely correct. People keep on reimplementing what browsers already provide, and they seldom do a good job of it. In fact, often it’s impossible to do a flawless job of it—e.g. you can’t get a custom dropdown to behave (not look, behave) like a native without some fairly detailed user-agent and platform matching (I mean things like whether selection is focus or not, and what Tab does when the dropdown is open and selection is not focus), quite apart from the other details that people often skip over (see https://www.w3.org/TR/wai-aria-practices/#Listbox for a summary); and scrolljacking is always bad because the primitives exposed are insufficient to reimplement scrollable areas.

This is an attitude problem with a large fraction of web developers that causes trouble for users. You should very strongly prefer to use a native element and technique for something if you can. And buttons… well, buttons are a great example of something fundamental that the browser has a good implementation of, which is often reimplemented annoyingly incorrectly.

Post reply on HN