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/
WebAssembly Studio
71–80 of 231 posts
Re: WebAssembly Studio
#72Earlier 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.
Re: WebAssembly Studio
#73Question for anyone with real WASM experience: what are your top recommended entry points / reference materials? AssemblyScript seems pretty approachable at 1st glance...
Also emscripten of course, for C/C++.
Re: WebAssembly Studio
#74The "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…
> 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
#75It 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.
"You loaded a page with JS but you also disabled JS execution, so it probably won't work"
Re: WebAssembly Studio
#76Earlier 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.
Re: WebAssembly Studio
#77Earlier 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…
Re: WebAssembly Studio
#78The "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 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
#79The "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…