51–60 of 231 posts
Earlier quoted context omitted.
There is a github link at he top right, you could start there.
I was talking about the general problem of new inaccessible apps being developed, not this specific project.
For example, do you know of a good way for developers with no disabilities to get an impression of how a site works in various screen readers?
Earlier quoted context omitted.
Today, I would probably choose something higher level than meddling around with Webpack directly.
Check out https://parceljs.org/ . It's how I start every project. I can always move to Webpack if I need more customization and complexity.
Anyone have a guess as to when WebAssembly will be able to directly access the DOM?
No recent updates unfortunately.
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 "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…
In this case, mwcampbell refers to a specific problem which is entirely avoidable and endemic of a flagrant disregard for the needs of accessibility - it would have been EASIER to make it accessible in Matt's example.
Earlier quoted context omitted.
How would you know it was a webasm IDE if it's just a blank page? (I thought it was going to be a music DAW when I clicked the link)
The url is webassembly.studio and the title is WebAssembly Studio
Earlier quoted context omitted.
I was talking about the general problem of new inaccessible apps being developed, not this specific project.
What do you think is a good starting point for developers who want to get better at this? For example, do you know of a good way for developers with no disabilities to get an impression of how a site works in various screen readers?
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 thing is damn snappy.
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'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…
Earlier quoted context omitted.
Thanks for sharing your perspective on this. Does anyone know if the web platform now provides a foolproof way to clear all default styling on a button or other standard control?
`appearance: none;` gets you a long way