WebAssembly Studio(webassembly.studio)
webassembly.studio
WebAssembly Studio
https://webassembly.studio
230 comments
EDIT-but-can't-edit-anymore:
I just noticed that https://makepad.dev/ hosts a different version that I think is newer. Skip the .nl one.
I just noticed that https://makepad.dev/ hosts a different version that I think is newer. Skip the .nl one.
Is it just me that finds all the text rendering on this page really bad?
It is, and it only supports ASCII so anyone who wants to write comments or text in Chinese, Japan, Korean, Thai, Arabic, etc can GTFO :(
Definitely not, it does not look pleasant to me either. At first I thought it was just the small font size, but I noticed it on the "Edit" page as well.
Everything is rendered directly to a canvas, at the very least it lacks subpixel rendering
One can use the Freetype library to render beautifully sharp text directly to a canvas with gamma-correct subpixel alpha coverage. Why this Rust website uses such blurry fonts, I don't know, it reminds me of playing an OpenGL/DirectX video game where the text is rendered using cached texture-filtered quads: maybe good enough for game UI, but not for intensive reading.
For those wondering why: subpixel rendering requires knowing the subpixel layout of the display. It’s something your OS knows, but your web browser doesn’t tell the website.
Also for those wondering how you can get subpixel AA on your canvases anyway: if you use a classic 2d rendering context (not WebGL), you can use canvas.getContext("2d", {alpha: false}) to create a canvas with a fully opaque background, which will also cause fillText to render with subpixel AA on most browsers.
What has good text rendering?
> And you can say what you want, the thing is damn snappy.
It's horribly slow on my computer, animations and scrolling happen at like 5fps. It also sends my cpu usage through the roof.
It's horribly slow on my computer, animations and scrolling happen at like 5fps. It also sends my cpu usage through the roof.
Uh, what about accessibility?
Interesting, thanks for sharing.
Curious whether source maps and breakpoints still work?
Yes that's a possibility
actually the experience should be even better than with sourcemapped JS. There was a demo of Wasm debugger on HN frontpage not a long time ago.
[deleted]
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.
I'd bet this was a "I already know this" decision, even as unnecessary as it is. I find it more bizarre that the tooling is written in TS, the WebAssembly source is Rust/C, and the test use file is plain JS. Some serious language personality disorder there. Some continuity would aid the DX here.
I only did one Gulp project and read it was a drastic improvement over Grunt, which I didn't use.
But most of my projects were done with Webpack and NPM scripts.
But most of my projects were done with Webpack and NPM scripts.
As much as people bemoan the complexity of Webpack, it's far superior to the (IMO) spaghetti code of gulp that inevitably results. I'll choose Webpack and npm scripts every time.
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.
It's how I start every project. I can always move to Webpack if I need more customization and complexity.
I was thinking about more integrated solutions like Next.js or Expo.
For smaller projects I agree. For larger projects, it's worth spending an hour or two on a custom Webpack config tuned to the project's needs IMO. In most cases it doesn't even take nearly that long.
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.
To move file around I use CopyWebpackPlugin or whatever other CLI tool called from npm scripts.
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.
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.
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?
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?
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/
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?
Did you want to leave a message? Perhaps some kind of cautionary tale?
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.
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.
what about https://www.animaapp.com/ ?
Figma is written in C++, compiled to WebAssembly. Probably the most advanced web-based design tool in the world.
I think they have like 4-5M users, and a $2B valuation.
https://madewithwebassembly.com/showcase/figma/
I think they have like 4-5M users, and a $2B valuation.
https://madewithwebassembly.com/showcase/figma/
Figma is an actual tool, written for the web. Lots of great engineering happening over there.
I know the Birth and death of JS gets mentioned quite a lot in WASM context (even as a joke) but I really don't see that being the case.
Most web applications/sites are simple, and won't need to be compiled at a lower level in order to work. On average JS developers will be cheaper than C/C++/Rust developers to hire, so I don't see shops changing their personnel or stack anytime soon, especially if the job is to knock up a website that's a bit interactive.
It simply won't be viable to have low-level engineers do things like "build a dropdown nav" or "make an interactive carousel", and these sort of tasks will always be around.
WASM is there to augment JS in places JS isn't suitable for, rather than outright replace it. JS will definitely still exist.
To answer your Q there's also a comprehensive list of projects using Web Assembly on this site: https://madewithwebassembly.com/all-projects
It simply won't be viable to have low-level engineers do things like "build a dropdown nav" or "make an interactive carousel", and these sort of tasks will always be around.
WASM is there to augment JS in places JS isn't suitable for, rather than outright replace it. JS will definitely still exist.
To answer your Q there's also a comprehensive list of projects using Web Assembly on this site: https://madewithwebassembly.com/all-projects
The problem is that it's hard to use as a primary language because of a lack of direct Web API access. So basically right now it's not a casual decision to say "I prefer X over JS, so I'll just use that instead because it targets WASM!" Because there's this enormous cost of crossing that API barrier (which means you'll be using some JS regardless, directly or indirectly).
So for now the value-proposition only really makes sense for a fairly narrow subset of projects: mostly ones where client-side pure-compute is a bottleneck. Theoretically API access is being worked on, but I think it's still a ways out.
So for now the value-proposition only really makes sense for a fairly narrow subset of projects: mostly ones where client-side pure-compute is a bottleneck. Theoretically API access is being worked on, but I think it's still a ways out.
Direct access seems improbable and even undesirable. Libraries can be written and shared to expose what you want to the wasm you need to run.
Lots of people would like the web to become a language-agnostic platform. I don't hate JS the way some do, but even I'd be excited about that prospect. That can never really happen until WASM has direct API access.
That said, I tried just now to find where I read that this was on the long-term roadmap and I'm having trouble finding it. So maybe you're right that it isn't currently planned.
That said, I tried just now to find where I read that this was on the long-term roadmap and I'm having trouble finding it. So maybe you're right that it isn't currently planned.
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.
For one, no one needs to install WASM, nor are they going to run into versioning issues because the OS has a hard dependency on it. Every single person with a computer, from a smart phone to render farm workstations, will have WASM support because those devices will have a browser. The only browser that doesn't support it is the legacy IE line of browsers, of which only 11 is still supported, and which only runs on systems that will happily run Edge, instead.
Devs can rely on the fact that users won't need to install a single thing, and users can rely on the fact that they're not going to have to go through the insanity that is "trying to install the right version of Boobletech(tm) Meep(r)" or, hell: "trying to get their OS to even acknowledge that the preinstalled version of java is over a decade old and it needs to stop using it instead of the new version you installed".
If your compiler can target WebAssembly, and your users are on computers with operating systems that are still supported, your WASM application will work for them, because everyone has a browser.
Devs can rely on the fact that users won't need to install a single thing, and users can rely on the fact that they're not going to have to go through the insanity that is "trying to install the right version of Boobletech(tm) Meep(r)" or, hell: "trying to get their OS to even acknowledge that the preinstalled version of java is over a decade old and it needs to stop using it instead of the new version you installed".
If your compiler can target WebAssembly, and your users are on computers with operating systems that are still supported, your WASM application will work for them, because everyone has a browser.
Unless your user is using a iPhone.
Not unless your iphone is a hand-me-down from someone who themselves got it as a hand-me-down?
https://caniuse.com/?search=wasm
https://caniuse.com/?search=wasm
Safari has support for WebAssembly.
I’m not sure either. There are some technical differences. WASM is more low-level than JVM bytecode, which is important for some applications and makes it a more normal compiler target. It’s more integrated with the rest of the browser: it doesn’t come with its own rectangle like Flash and Java did, but instead manipulates the DOM just like (or at the moment, only through) JavaScript. And it’s a true open standard, not a corporate-controlled platform.
Do these differences really matter, or is it mostly just the timing?
Do these differences really matter, or is it mostly just the timing?
WASM is definitely more low-level than JVM byte code right now... but I'm not sure it'll remain that way given the many proposals that are very likely to be implemented in the future (even though it's taking a long time for even simple ones, like multi-value returns, to get into the standard). For example, with WASI and GC, which will finally enable direct access to the DOM, how much lower-level will WASM be compared to JVM? Not much, I would say.
The big difference is that WASM, from the beginning, is supported by all the browsers natively (a consequence of it not being a proprietary technology, but an open standard), not as a plugin... If Java had started that way, the story would've turned out quite differently (but we know that at the time, the browser everyone was using was made by Microsoft, and Sun was a competitor so this would've never happened).
The big difference is that WASM, from the beginning, is supported by all the browsers natively (a consequence of it not being a proprietary technology, but an open standard), not as a plugin... If Java had started that way, the story would've turned out quite differently (but we know that at the time, the browser everyone was using was made by Microsoft, and Sun was a competitor so this would've never happened).
It starts immediately, while any embedded java applet took forever and looked really ugly. We've also done this with flash apps
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 host system, so the security boundary isn't as well defined. Users can also be tricked to trust malicious applets, which is a built-in mechanism to escape the sandbox; browsers hopefully will not provide this feature for their wasm runtimes.
> the JRE itself has unmitigated access to the host system
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.
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.
Interesting thought experiment. However, you have to realize that Sun wasn’t a charity. At the time, platform vendors were were hoping to target intranet applications for the enterprise. Microsoft had a similar concept for trusted applications with IE’s “Active Scripting”, with very similar results in terms of (non)security.
Ruffle - A Flash Player emulator over WebAssembly:
https://github.com/ruffle-rs/ruffle
Shopify is using WASM in production [0]
[0] https://shopify.engineering/shopify-webassembly
[0] https://shopify.engineering/shopify-webassembly
We release a web-based ray tracer built with WASM that's integrated into our existing 3D/AR/VR platform: https://twitter.com/ksqio/status/1334962197324320768?s=20
Additional examples of WebAssembly being used at scale that I haven't seen others mention yet:
Microsoft - https://www.microsoft.com/en-us/garage/wall-of-fame/calc-ts-...
Adobe - https://medium.com/adobetech/acrobat-on-the-web-powered-by-w...
Fastly - https://www.fastly.com/blog/announcing-lucet-fastly-native-w...
Microsoft - https://www.microsoft.com/en-us/garage/wall-of-fame/calc-ts-...
Adobe - https://medium.com/adobetech/acrobat-on-the-web-powered-by-w...
Fastly - https://www.fastly.com/blog/announcing-lucet-fastly-native-w...
Google Earth: https://earth.google.com/web/
Side note: Does anyone know why that video isn't on Youtube? I've tried to find it, but alas I can't. Copyright? Moral reasons? What?
https://www.youtube.com/results?search_query=gary+bernhardt+...
https://www.youtube.com/results?search_query=gary+bernhardt+...
Twitch also appears to be using it, although I don't know what for.
Perspective is developed at JPMorgan https://github.com/finos/perspective/
There site which aggregate prod use cases:
https://madewithwebassembly.com/
Unity, the very popular 3D game engine, can “export” games to run in the browser. WebAssembly is undoubtedly involved.
Google Duo's web client has some wasm code cached under the name 'wasm-clips'.
[deleted]
I find it a nice experience, but as far as I am aware it is pretty much dead, the website just happens to keep running.
Yep, it's not actively developed : https://github.com/wasdk/WebAssemblyStudio/commits/master
Bummer. Seemed like a decent tool, too. :/
I hope wasm gets serious attention by the Bazel team. I've personally been thinking of it as "the JVM done the right way". Still lots of progress needs to be made but it's very exciting to have another cross-platform multi-language VM.
Question for anyone with real WASM experience: what are your top recommended entry points / reference materials? AssemblyScript seems pretty approachable at 1st glance...
Rust has the best tooling for wasm and is easiest to get started with, in my opinion.
`rustup target add wasm32-unknown-unknown`
`cargo build --target=wasm32-unknown-unknown`
Is all you need to compile a Rust library to a `.wasm` file. (almost, you also need a setting in Cargo.toml: [lib] crate-type = ["cdylib", "rlib"] )
In the browser you can get access to DOM apis via web-sys.
The documentation has quite a lot of examples and info: https://rustwasm.github.io/wasm-bindgen/web-sys/index.html
wasm-pack (https://github.com/rustwasm/wasm-pack) makes building code for the browser easy.
`rustup target add wasm32-unknown-unknown`
`cargo build --target=wasm32-unknown-unknown`
Is all you need to compile a Rust library to a `.wasm` file. (almost, you also need a setting in Cargo.toml: [lib] crate-type = ["cdylib", "rlib"] )
In the browser you can get access to DOM apis via web-sys.
The documentation has quite a lot of examples and info: https://rustwasm.github.io/wasm-bindgen/web-sys/index.html
wasm-pack (https://github.com/rustwasm/wasm-pack) makes building code for the browser easy.
> In the browser you can get access to DOM apis via web-sys.
Wow! The last time I looked, doing anything remotely like this was a gigantic pain, in any language.
I guess it's finally time for me to get around to learning Rust.
Wow! The last time I looked, doing anything remotely like this was a gigantic pain, in any language.
I guess it's finally time for me to get around to learning Rust.
AssemblyScript is one of the best options, because if the only thing you care about is some high level language that outputs WebAssembly, then you are still using Web related tools.
Then D is quite easy to use (LDC alongside betterC mode, runtime is still not fully ported).
Followed by TinyGo, Rust, C#, Nim.
I would leave Emscripten, C and C++, only for porting existing code into the Web, as even with the sandbox memory corruptions of data allocated in the linear memory blocks are susceptible to occur.
Then D is quite easy to use (LDC alongside betterC mode, runtime is still not fully ported).
Followed by TinyGo, Rust, C#, Nim.
I would leave Emscripten, C and C++, only for porting existing code into the Web, as even with the sandbox memory corruptions of data allocated in the linear memory blocks are susceptible to occur.
> corruptions of data allocated in the linear memory blocks are susceptible to occur
I don't know if I quite understand this. Is this a web-assembly specific thing, or just the standard C / C++ are "unsafe by default" languages which can cause memory corruption etc because e.g. of off by one errors in pointer arithmetic and so on.
I don't know if I quite understand this. Is this a web-assembly specific thing, or just the standard C / C++ are "unsafe by default" languages which can cause memory corruption etc because e.g. of off by one errors in pointer arithmetic and so on.
The usual stuff with C and C++.
WebAssembly doesn't do bounds checking, besides being in bounds of a linear memory segment.
Basically the access is still in bounds of the allocated memory, but not the cells that one actually wanted to access.
From security point of view, while the WebAssembly module is sandboxes, such corruptions can be triggered from the outside, changing the behaviour of the public API.
WebAssembly doesn't do bounds checking, besides being in bounds of a linear memory segment.
Basically the access is still in bounds of the allocated memory, but not the cells that one actually wanted to access.
From security point of view, while the WebAssembly module is sandboxes, such corruptions can be triggered from the outside, changing the behaviour of the public API.
Embedded engineer here.
We used it to implement a complex, browser-accessible debugger interface for an industrial analyser device. Fast real-time graphs, buttons, menus, etc...
It typically loads in a few seconds in your browser. Works wonders.
We used emscripten + imgui + implot ... All C++ and zero interaction with the low-level WASM itself.
Recommended.
We used it to implement a complex, browser-accessible debugger interface for an industrial analyser device. Fast real-time graphs, buttons, menus, etc...
It typically loads in a few seconds in your browser. Works wonders.
We used emscripten + imgui + implot ... All C++ and zero interaction with the low-level WASM itself.
Recommended.
Zig has excellent support for WebAssembly (out of the box, no need to install anything else). The resulting modules are small and fast.
I've played around with Haskell via the Asteruis project : https://github.com/tweag/asterius
Also emscripten of course, for C/C++.
Also emscripten of course, for C/C++.
Huh. I created a C project, added #include <stdio.h> and printf("hello world") to the skeleton. "Build & Run" doesn't seem to do anything but compile and print the not very useful message of "[error]: TypeError: second argument must be an object".
If you check out the C Hello World project you'll see there's quite a bit more to it, and it seems to be explained quite thoroughly.
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, using its own home-grown components for basic things like buttons.
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. I suppose we could also blame the web platform for making it hard enough to customize the look of a standard button that the developer would reach for the div tag. What do we do about this?
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, using its own home-grown components for basic things like buttons.
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. I suppose we could also blame the web platform for making it hard enough to customize the look of a standard button that the developer would reach for the div tag. What do we do about this?
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 somehow translating thoughts into perfect UI automatically we can try to add coverage to these projects as we can prioritize it. After all that's why they are being built in the open with an open license, so others can help add functionality.
As far as what we can do about it I suppose outside of somehow translating thoughts into perfect UI automatically we can try to add coverage to these projects as we can prioritize it. After all that's why they are being built in the open with an open license, so others can help add functionality.
> > 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 <button>, 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 <button> to retain its default display property. Within flowing text, it can never break naturally onto the next line, whereas an <a> 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 <span> not a <div> because <button> can only contain phrasing elements.
> 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 <button>, 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 <button> to retain its default display property. Within flowing text, it can never break naturally onto the next line, whereas an <a> 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 <span> not a <div> because <button> can only contain phrasing elements.
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 <button>, and this is just one of the reasons why.
(c) <button> 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 <button> or any other technique). That’s not what buttons are.
(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 <button>, and this is just one of the reasons why.
(c) <button> 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 <button> or any other technique). That’s not what buttons are.
> 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.
This is my biggest pet peeve with so many modern websites and web-based desktop apps. It's not just a matter of being semantically correct in some abstract sense, it completely breaks the user experience for a keyboard user like me.
If you have a form with, say, two text fields, I expect to be able to type into the first field, hit Tab to the second one, type into that one, and press Enter to submit.
All too often, when I press Enter, nothing happens! This is because of the very problem you described: the developer used a click event handler on the submit button instead of a submit handler on the form as they should have.
It's such an easy thing to get right; why do so many get it wrong?
This is my biggest pet peeve with so many modern websites and web-based desktop apps. It's not just a matter of being semantically correct in some abstract sense, it completely breaks the user experience for a keyboard user like me.
If you have a form with, say, two text fields, I expect to be able to type into the first field, hit Tab to the second one, type into that one, and press Enter to submit.
All too often, when I press Enter, nothing happens! This is because of the very problem you described: the developer used a click event handler on the submit button instead of a submit handler on the form as they should have.
It's such an easy thing to get right; why do so many get it wrong?
I find this very interesting and is something I get right as a habit.
Is there any resources pointing to such best practices and/or accessibility?
Is there any resources pointing to such best practices and/or accessibility?
I will answer myself with the latest resource I found: https://webaim.org/intro/
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 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.
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.
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 make by adding additional ARIA markup to the UI?
I might be missing something, how would it have been easier to make by adding additional ARIA markup to the UI?
The clickable divs should be focusable and have the aria button role. <div tabindex="0" role="button">...</div>
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
Things to read:
https://www.w3.org/TR/wai-aria-practices/#read_me_first
https://www.w3.org/TR/wai-aria-practices/#button
Agreed they should to have accessibility support.
They could have just used off-the-shelf components for the first iteration.
Using the builtin browser button element isn't without other things to then fix in the software either, "(getting anything to automagically work in UI is a pain still)".
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.
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.
You don't add ARIA tags to the UI - you use UI elements which are already accessible. You should never, ever make a button out of a div. The JavaScript community needs to grow up and stop chasing shiny things, because they're leaving huge numbers of people behind in their wake.
Bikeshedding about the best approach to making it accessible aside I think we all agree there was no out of the box button with the exact functionality and styling the project needed. Many ways to build such a thing but all of which require someone actually making the software that way as part of the project scope. Difficult? Not really. Priority to implement from day 1 in this project? Well that's what started the conversation I suppose.
> I think we all agree there was no out of the box button with the exact functionality and styling the project needed
We don't agree on that. Styling a real button to look the same way this does would require basically the same amount of work as styling a div. The only difference for most people is that you would need to search for a style clear for buttons, which will be the first result in DuckDuckGo: https://css-tricks.com/overriding-default-button-styles/
And it's a little bit debatable if you even want that style clear, because you should be using some of the stuff that buttons give you for free like graphical changes when the button is pressed, visual indication of focus, etc... That's all stuff that the final developer didn't even know they were missing from the final project.
So it's not even really a question about "does the button look exactly like what I want." Many times, 'exactly what the dev wants' is explicitly the wrong choice to make. Most developers don't know every graphical effect and interaction that a button should have, and they shouldn't have to. The point of native components is to make this stuff easier; you don't have to think about every interaction and use case that every non-typical user might require.
----
In Firefox, I opened the dev tools, changed the div to a button, and added one line of CSS:
No bikeshedding needed here, I didn't even need to look up a button reset style.
We don't agree on that. Styling a real button to look the same way this does would require basically the same amount of work as styling a div. The only difference for most people is that you would need to search for a style clear for buttons, which will be the first result in DuckDuckGo: https://css-tricks.com/overriding-default-button-styles/
And it's a little bit debatable if you even want that style clear, because you should be using some of the stuff that buttons give you for free like graphical changes when the button is pressed, visual indication of focus, etc... That's all stuff that the final developer didn't even know they were missing from the final project.
So it's not even really a question about "does the button look exactly like what I want." Many times, 'exactly what the dev wants' is explicitly the wrong choice to make. Most developers don't know every graphical effect and interaction that a button should have, and they shouldn't have to. The point of native components is to make this stuff easier; you don't have to think about every interaction and use case that every non-typical user might require.
----
In Firefox, I opened the dev tools, changed the div to a button, and added one line of CSS:
border: none;
No bikeshedding needed here, I didn't even need to look up a button reset style.
I'm REALLY not looking for a debate on what technical changes are needed to make this accessible but I tried changing it to a button in the page (with border: none;) and immediately I notice it's larger and the underline hover effect is broken. It's also floating verically by a pixel. I'm sure there are other effects I haven't noticed immediately. This is exactly what I'm talking about on how it's not just free, there is work to making it work exactly the way the developer wanted it for the project.
Maybe you think a button shouldn't look like that. Maybe you think a button should prioritize <list of things> before style. Maybe you just like to do something your own way. That's great, go ahead on your own project or hire this person for it. None of that has anything to do with why this person built this tool the way they wanted or makes it any easier for them to do so while adding better accessibility.
Maybe you think a button shouldn't look like that. Maybe you think a button should prioritize <list of things> before style. Maybe you just like to do something your own way. That's great, go ahead on your own project or hire this person for it. None of that has anything to do with why this person built this tool the way they wanted or makes it any easier for them to do so while adding better accessibility.
Are you setting it as an actual style under the `.button` class or are you attaching it to the element?
I don't see any of the effects you're talking about. Size is the same, no pixel offset. If you change the div (not the selected SVG, but the div itself) into a button and then add `border: none` to the .button class, there should be no visual changes at all. I'm checking both the Firefox and Chrome dev tools, it's a 24 px high button with 8 pixels of padding.
If there's some other visual change that goes along with that, I can't find it.
----
> None of that has anything to do with why this person built this tool the way they wanted or makes it any easier for them to do so while adding better accessibility.
There's another side to this though which is that it is genuinely helpful to tell people that there are very simple changes they could make to increase accessibility on a platform that we have a vested interest in making accessible.
It's not helpful to be a jerk about it, but I'm not going to act like there's no right way to build something like this. I understand why someone might cut some corners on a quick project, or why they might not know everything there is to know about accessibility. I don't fault any developer over that. But there is a correct engineering answer to the question of how a button should be designed, and it actually does genuinely impact real people in the real world.
Part of what we're doing here is trying to as much as possible without being jerks get across the idea that accessibility matters. We're trying to get across the point that it's not OK to have the web mostly not work for blind people and to say, "there aren't enough of them to care about."
And especially in an area where fixing the problem is genuinely way less work than even having this conversation, and where fixing it would have zero downsides for the finished project, it is genuinely disheartening to see people putting forward the idea that literally any extra work at all means that accessibility has to be optional.
How far are you going to take that? Is it unreasonable for me to ask people to spend an extra minute captioning the photos they upload to Twitter? There are categories of things where it reasonable to ask people to put in a tiny bit of extra work so that the web doesn't completely fail in its mission to be a universally accessible platform. We ask developers (even Open Source developers) to put in far more work over way more trivial, meaningless things than this.
So yes, maybe it would have required an extra minute or two of work to style this as a button. And if the developer didn't know how to do that, fine, I'm not here to shame people for not knowing things, I have no ill will towards the developer for making that mistake. But I am here to shame people who say that one extra minute of work is too much for accessibility advocates to expect, and that asking developers to even think about accessibility is inherently unreasonable. We want developers to care about accessibility, we aren't neutral on that. We want developers to have a code of ethics and values that prioritizes equal access for everyone. That's part of the value ethos of the web as a platform.
We spend so much time as advocates trying to dance around that issue and trying to make it easier for people to be 'accidentally' accessible when they build on the web, and to add tools and features that make accessibility the easier, natural engineering path. All of that is good, and we should keep doing that, and the accessible path here is the easier path, but on the other hand at some point we also have to be willing to say, "no, we expect you to genuinely care about blind people at least a little bit."
I don't see any of the effects you're talking about. Size is the same, no pixel offset. If you change the div (not the selected SVG, but the div itself) into a button and then add `border: none` to the .button class, there should be no visual changes at all. I'm checking both the Firefox and Chrome dev tools, it's a 24 px high button with 8 pixels of padding.
If there's some other visual change that goes along with that, I can't find it.
----
> None of that has anything to do with why this person built this tool the way they wanted or makes it any easier for them to do so while adding better accessibility.
There's another side to this though which is that it is genuinely helpful to tell people that there are very simple changes they could make to increase accessibility on a platform that we have a vested interest in making accessible.
It's not helpful to be a jerk about it, but I'm not going to act like there's no right way to build something like this. I understand why someone might cut some corners on a quick project, or why they might not know everything there is to know about accessibility. I don't fault any developer over that. But there is a correct engineering answer to the question of how a button should be designed, and it actually does genuinely impact real people in the real world.
Part of what we're doing here is trying to as much as possible without being jerks get across the idea that accessibility matters. We're trying to get across the point that it's not OK to have the web mostly not work for blind people and to say, "there aren't enough of them to care about."
And especially in an area where fixing the problem is genuinely way less work than even having this conversation, and where fixing it would have zero downsides for the finished project, it is genuinely disheartening to see people putting forward the idea that literally any extra work at all means that accessibility has to be optional.
How far are you going to take that? Is it unreasonable for me to ask people to spend an extra minute captioning the photos they upload to Twitter? There are categories of things where it reasonable to ask people to put in a tiny bit of extra work so that the web doesn't completely fail in its mission to be a universally accessible platform. We ask developers (even Open Source developers) to put in far more work over way more trivial, meaningless things than this.
So yes, maybe it would have required an extra minute or two of work to style this as a button. And if the developer didn't know how to do that, fine, I'm not here to shame people for not knowing things, I have no ill will towards the developer for making that mistake. But I am here to shame people who say that one extra minute of work is too much for accessibility advocates to expect, and that asking developers to even think about accessibility is inherently unreasonable. We want developers to care about accessibility, we aren't neutral on that. We want developers to have a code of ethics and values that prioritizes equal access for everyone. That's part of the value ethos of the web as a platform.
We spend so much time as advocates trying to dance around that issue and trying to make it easier for people to be 'accidentally' accessible when they build on the web, and to add tools and features that make accessibility the easier, natural engineering path. All of that is good, and we should keep doing that, and the accessible path here is the easier path, but on the other hand at some point we also have to be willing to say, "no, we expect you to genuinely care about blind people at least a little bit."
https://i.imgur.com/ztxBRHP.png
Since somehow we're still talking about how to do it I'd simply do "all: unset" if I don't care about IE and want to fully control the style. In that way the defaults go out the window and I can build up to the style I want.
If you don't do this approach you're going to want to keep in mind differences in default whitespace handling and alignment/sizing model defaults which are going to be different in a button vs a typical <div> container.
.
Nothing wrong with going into a technical comment or discussion in hopes of sharing knowledge but that's not what was being talked about here. Look how long you and I have been talking about a single button in the UI. Look how many other comments there are about this. Now go back to the original comment "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.". Ignoring that it's talking about a COMPLETELY different approach to making the button accessible the assumption is the developer is uninformed about accessibility. My argument is knowledgeable or not it's a lot of work for a passion project and not something reasonable to expect be done in one. If you want to make a PR to add user accessibility so they can understand that's great but I think you'll find it was a lot more work than figuring out how to make this one button be marked for a screen reader. You may also (likely) find they knew many of the things that would be needed to make it accessible but went with what was quick and easy for the passion project, especially considering the thing is still marked beta.
Taking that to the other part of your content no it's not alright for you to decide what's acceptable code quality for someone else to be able to share their free project. It'd be nice if it was accessible to the blind, it'd also be nice to have Chinese and Indian translations. None of these is something reasonable to expect from a project like this simply because it was shared for free. A government project definitely. A commercial project very much so. Some person's passion project? No, you don't get to decide when it's usable by enough people for them to share it with others. And you shouldn't expect open source developers to do anything for you, always be happy they picked something up they didn't want/need themselves. Otherwise do the work or pay them to, don't just demand they follow your standards. This is very different than making a helpful PR or comment about how to do it which is on the "totally acceptable" side of the fence.
I'm not here to shame anybody but if I was it'd be people that see an free and open source project and the first thing they think is to comment to shame the author about it.
Since somehow we're still talking about how to do it I'd simply do "all: unset" if I don't care about IE and want to fully control the style. In that way the defaults go out the window and I can build up to the style I want.
If you don't do this approach you're going to want to keep in mind differences in default whitespace handling and alignment/sizing model defaults which are going to be different in a button vs a typical <div> container.
.
Nothing wrong with going into a technical comment or discussion in hopes of sharing knowledge but that's not what was being talked about here. Look how long you and I have been talking about a single button in the UI. Look how many other comments there are about this. Now go back to the original comment "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.". Ignoring that it's talking about a COMPLETELY different approach to making the button accessible the assumption is the developer is uninformed about accessibility. My argument is knowledgeable or not it's a lot of work for a passion project and not something reasonable to expect be done in one. If you want to make a PR to add user accessibility so they can understand that's great but I think you'll find it was a lot more work than figuring out how to make this one button be marked for a screen reader. You may also (likely) find they knew many of the things that would be needed to make it accessible but went with what was quick and easy for the passion project, especially considering the thing is still marked beta.
Taking that to the other part of your content no it's not alright for you to decide what's acceptable code quality for someone else to be able to share their free project. It'd be nice if it was accessible to the blind, it'd also be nice to have Chinese and Indian translations. None of these is something reasonable to expect from a project like this simply because it was shared for free. A government project definitely. A commercial project very much so. Some person's passion project? No, you don't get to decide when it's usable by enough people for them to share it with others. And you shouldn't expect open source developers to do anything for you, always be happy they picked something up they didn't want/need themselves. Otherwise do the work or pay them to, don't just demand they follow your standards. This is very different than making a helpful PR or comment about how to do it which is on the "totally acceptable" side of the fence.
I'm not here to shame anybody but if I was it'd be people that see an free and open source project and the first thing they think is to comment to shame the author about it.
I'm not sure what to say about your image other than that you are not setting styles the same way I am, because that doesn't happen when I make those changes. I'm not sure what the difference is, maybe there's something special about the platform you're on that doesn't show up on my desktop computer. In either case, adjust the bottom margin by -1 pixel and move on with your life.
> the assumption is the developer is uninformed about accessibility.
The assumption that the developer is uninformed about accessibility is the kind assumption, not the mean one. The alternative implication, that they knew about accessibility but chose to use inaccessible markup instead, is a much worse reading of the situation.
The kind reading of this comment is that 20 years after we started having this conversation, we still have failed to educate developers on how to use a button. That is something that's valid to be sad about, it reflects nothing on the developer in question. It's a failure of web education.
> None of these is something reasonable to expect from a project like this simply because it was shared for free.
There's a fundamental difference here between us then. I'm not shaming the developer, I'm not mad that they didn't know in advance how to be accessible. I'm not mad that they released a project early without thinking about accessibility. But I am completely unapologetic about the idea that most developers on the web should be thinking about accessibility, and that it is reasonable to mention accessibility on public projects submitted into public spaces.
The web as a platform and a community cares about accessibility. So if you come onto the web and start making stuff, we will look at the accessibility and we will comment on it. We do that because, from the perspective of accessibility advocates, there are three options:
1. The technology gets restricted in some way so that you're forced to be accessible (maybe click handlers can't be attached to divs or something).
2. The law steps in and requires that anything beyond a hobby project be accessible, and we just kind of accept that blind people are excluded from the hobby web (not really acceptable to us).
3. We educate people and promote a value system that encourages developers to care about accessibility when possible.
We prefer the third option.
I want to encourage people to think that very basic accessibility accommodations are the standard normal thing that developers should think about. In my mind, this is the kinder option, because the alternative is stricter laws and more restrictive technology and frameworks that make it harder to do creative things.
Of course people can release whatever they want whenever they want. Of course, people can show off public projects that are unfinished or that have problems. Of course nobody can require anyone to release anything for free. But similarly, of course people in the public can point out that those projects aren't fitting into the web ethos. The only way we are going to make progress on accessibility in the web is by encouraging a culture of people who care about accessibility.
The tech changes can only go so far. We can make HTML more semantic, but we can't auto-caption images. At some point, people have to be convinced that this is worth caring about. Open Source does not mean we need to throw away any values about what good software should look like. We can be grateful that the author made a cool IDE while still openly acknowledging that it doesn't in its current state conform to shared web values.
> the assumption is the developer is uninformed about accessibility.
The assumption that the developer is uninformed about accessibility is the kind assumption, not the mean one. The alternative implication, that they knew about accessibility but chose to use inaccessible markup instead, is a much worse reading of the situation.
The kind reading of this comment is that 20 years after we started having this conversation, we still have failed to educate developers on how to use a button. That is something that's valid to be sad about, it reflects nothing on the developer in question. It's a failure of web education.
> None of these is something reasonable to expect from a project like this simply because it was shared for free.
There's a fundamental difference here between us then. I'm not shaming the developer, I'm not mad that they didn't know in advance how to be accessible. I'm not mad that they released a project early without thinking about accessibility. But I am completely unapologetic about the idea that most developers on the web should be thinking about accessibility, and that it is reasonable to mention accessibility on public projects submitted into public spaces.
The web as a platform and a community cares about accessibility. So if you come onto the web and start making stuff, we will look at the accessibility and we will comment on it. We do that because, from the perspective of accessibility advocates, there are three options:
1. The technology gets restricted in some way so that you're forced to be accessible (maybe click handlers can't be attached to divs or something).
2. The law steps in and requires that anything beyond a hobby project be accessible, and we just kind of accept that blind people are excluded from the hobby web (not really acceptable to us).
3. We educate people and promote a value system that encourages developers to care about accessibility when possible.
We prefer the third option.
I want to encourage people to think that very basic accessibility accommodations are the standard normal thing that developers should think about. In my mind, this is the kinder option, because the alternative is stricter laws and more restrictive technology and frameworks that make it harder to do creative things.
Of course people can release whatever they want whenever they want. Of course, people can show off public projects that are unfinished or that have problems. Of course nobody can require anyone to release anything for free. But similarly, of course people in the public can point out that those projects aren't fitting into the web ethos. The only way we are going to make progress on accessibility in the web is by encouraging a culture of people who care about accessibility.
The tech changes can only go so far. We can make HTML more semantic, but we can't auto-caption images. At some point, people have to be convinced that this is worth caring about. Open Source does not mean we need to throw away any values about what good software should look like. We can be grateful that the author made a cool IDE while still openly acknowledging that it doesn't in its current state conform to shared web values.
> The kind reading of this comment is that 20 years after we started having this conversation, we still have failed to educate developers on how to use a button. That is something that's valid to be sad about, it reflects nothing on the developer in question. It's a failure of web education.
Thank you. I'm embarrassed at how melodramatic that part of my original comment was, but I'm glad someone gets it.
Thank you. I'm embarrassed at how melodramatic that part of my original comment was, but I'm glad someone gets it.
> In either case, adjust the bottom margin by -1 pixel and move on with your life.
Like I said there are other things broken about this, probably other side effects I didn't notice from this single button instance, and a LOT more to a UI than a single button to fix. My point isn't it can't be done at all my point is your "just add this one line" is a strawman detracting from the fact it is additional effort to add accessibility support to an overall project and this effort is a real world reason projects like this one don't have accessible UI, not because the dev is a screw up.
> The assumption that the developer is uninformed about accessibility is the kind assumption, not the mean one. The alternative implication, that they knew about accessibility but chose to use inaccessible markup instead, is a much worse reading of the situation.
My argument is it's NOT unkind to only build what you need in a project you decide to share freely. It's kind to share anything at all, regardless how incomplete it is. It may not even function at all for anyone, it comes with no guarantees other than you have the right to modify it as you please.
> There's a fundamental difference here between us then... I am completely unapologetic about the idea that most developers on the web should be thinking about accessibility, and that it is reasonable to mention accessibility on public projects submitted into public spaces.
I'd agree with the first part but with a slight twist on the reasoning. I think it's fine to mention on something like this as long as it's without trying to blame, shame, or demand something of the developer.
.
To review the original comment (since I think we've detracted quite far from it now):
> 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, using its own home-grown components for basic things like buttons.
The first paragraph is spot on with what you're talking about and I think perfectly acceptable and even helpful to those that might not know about ARIA or how to approach the problem. Albeit the second paragraph ideally could have used some helpful examples on how to make it so rather than lamenting the developer did it the way they did I think it's alright, I never really commented on it.
> 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. I suppose we could also blame the web platform for making it hard enough to customize the look of a standard button that the developer would reach for the div tag. What do we do about this?
Is when the question is posed that I responded about. This is what goes from "educating and promoting" to "shaming for not being as moral as I'd like", literally looking to place moral blame on free and open code being shared for not being good enough for the author and asking what we do about this. When I responded:
> 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 somehow translating thoughts into perfect UI automatically we can try to add coverage to these projects as we can prioritize it. After all that's why they are being built in the open with an open license, so others can help add functionality.
None of my comment was saying we shouldn't promote accessibility or mention accessibility issues. It did call out that the initial question ignored the most tangible problem - implementing accessibility is NOT done for free (regardless how much you want to convince me it's just one line it's still not free anyways) and that's why it didn't make it on the top of the todo list for an incomplete open source project.
.
> and that it is reasonable to mention accessibility on public projects submitted into public spaces.
Reasonable to mention absolutely, and probably helpful to all. As mentioned that's not all this thread has been about though.
> I want to encourage people to think that very basic accessibility accommodations are the standard normal thing that developers should think about. In my mind, this is the kinder option, because the alternative is stricter laws and more restrictive technology and frameworks that make it harder to do creative things.
I definitely agree on the encouragement side of things, even for projects like this. I'm even in support of stricter accessibility laws for commercial and government software. I'm just not in support, kind methods or not, of either blaming, shaming, or restricting people from sharing free and open code or making demands they do certain things when they write it on their own accord. If you see something about an free open source project you don't think was done the best way it's great to try to talk about how it could be done better, it's even greater if you can help make it the way you think it should be. If you think the developer was in the wrong or you need to talk about blame or they should be shamed for it then yeah, I think that's our fundamental disagreement. I see it as something they haven't been able to focus on not something that makes them a bad developer because they didn't do their free work well enough for my moral standard. Just like I said, I don't expect developers to have a multi-lingual UI either but it'd be great if someone wanted to come by a project and help make it happen so more people can use it.
.
Anyways I think unless you have a particular question or say I was particularly far off on understanding something here I've said about as much as I can say about it and don't intend to drag it out more for minor details. I do appreciate your time and thoughts on this, sincerely, and will definitely read any message you respond with even if I don't respond. Cheers and happy new year
Like I said there are other things broken about this, probably other side effects I didn't notice from this single button instance, and a LOT more to a UI than a single button to fix. My point isn't it can't be done at all my point is your "just add this one line" is a strawman detracting from the fact it is additional effort to add accessibility support to an overall project and this effort is a real world reason projects like this one don't have accessible UI, not because the dev is a screw up.
> The assumption that the developer is uninformed about accessibility is the kind assumption, not the mean one. The alternative implication, that they knew about accessibility but chose to use inaccessible markup instead, is a much worse reading of the situation.
My argument is it's NOT unkind to only build what you need in a project you decide to share freely. It's kind to share anything at all, regardless how incomplete it is. It may not even function at all for anyone, it comes with no guarantees other than you have the right to modify it as you please.
> There's a fundamental difference here between us then... I am completely unapologetic about the idea that most developers on the web should be thinking about accessibility, and that it is reasonable to mention accessibility on public projects submitted into public spaces.
I'd agree with the first part but with a slight twist on the reasoning. I think it's fine to mention on something like this as long as it's without trying to blame, shame, or demand something of the developer.
.
To review the original comment (since I think we've detracted quite far from it now):
> 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, using its own home-grown components for basic things like buttons.
The first paragraph is spot on with what you're talking about and I think perfectly acceptable and even helpful to those that might not know about ARIA or how to approach the problem. Albeit the second paragraph ideally could have used some helpful examples on how to make it so rather than lamenting the developer did it the way they did I think it's alright, I never really commented on it.
> 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. I suppose we could also blame the web platform for making it hard enough to customize the look of a standard button that the developer would reach for the div tag. What do we do about this?
Is when the question is posed that I responded about. This is what goes from "educating and promoting" to "shaming for not being as moral as I'd like", literally looking to place moral blame on free and open code being shared for not being good enough for the author and asking what we do about this. When I responded:
> 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 somehow translating thoughts into perfect UI automatically we can try to add coverage to these projects as we can prioritize it. After all that's why they are being built in the open with an open license, so others can help add functionality.
None of my comment was saying we shouldn't promote accessibility or mention accessibility issues. It did call out that the initial question ignored the most tangible problem - implementing accessibility is NOT done for free (regardless how much you want to convince me it's just one line it's still not free anyways) and that's why it didn't make it on the top of the todo list for an incomplete open source project.
.
> and that it is reasonable to mention accessibility on public projects submitted into public spaces.
Reasonable to mention absolutely, and probably helpful to all. As mentioned that's not all this thread has been about though.
> I want to encourage people to think that very basic accessibility accommodations are the standard normal thing that developers should think about. In my mind, this is the kinder option, because the alternative is stricter laws and more restrictive technology and frameworks that make it harder to do creative things.
I definitely agree on the encouragement side of things, even for projects like this. I'm even in support of stricter accessibility laws for commercial and government software. I'm just not in support, kind methods or not, of either blaming, shaming, or restricting people from sharing free and open code or making demands they do certain things when they write it on their own accord. If you see something about an free open source project you don't think was done the best way it's great to try to talk about how it could be done better, it's even greater if you can help make it the way you think it should be. If you think the developer was in the wrong or you need to talk about blame or they should be shamed for it then yeah, I think that's our fundamental disagreement. I see it as something they haven't been able to focus on not something that makes them a bad developer because they didn't do their free work well enough for my moral standard. Just like I said, I don't expect developers to have a multi-lingual UI either but it'd be great if someone wanted to come by a project and help make it happen so more people can use it.
.
Anyways I think unless you have a particular question or say I was particularly far off on understanding something here I've said about as much as I can say about it and don't intend to drag it out more for minor details. I do appreciate your time and thoughts on this, sincerely, and will definitely read any message you respond with even if I don't respond. Cheers and happy new year
How do you know what styling the project needed? What styling requires a button to stop being a button?
> How do you know what styling the project needed?
I don't know what the project needed but I'll assume the author of the dialog knew and didn't purposefully pick a harder way to do it that intentionally spited others rather picked the easiest way to meet the styling goals.
> What styling requires a button to stop being a button?
None, did anyone ever claim you can't style a button to be whatever you want with more effort?
I don't know what the project needed but I'll assume the author of the dialog knew and didn't purposefully pick a harder way to do it that intentionally spited others rather picked the easiest way to meet the styling goals.
> What styling requires a button to stop being a button?
None, did anyone ever claim you can't style a button to be whatever you want with more effort?
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.
When I decided to make myself a personal website this summer, my goals were:
• 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.
• 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.
Right? One of my peeves with a lot of developers is when they treat every programming project like it's a commercial start up. There's no reason "learning to implement custom buttons" can't be on your list of goals.
Depends on whether the idea behind "learn to implement custom buttons" is "because I want to have custom buttons on my website" or "because I want to be able to use this knowledge on future projects."
If you want to learn to make custom buttons with the idea being to be able to apply that knowledge elsewhere, you probably ought to learn to do them accessibly.
If you want to learn to make custom buttons with the idea being to be able to apply that knowledge elsewhere, you probably ought to learn to do them accessibly.
There are about 100 ways to do any given thing when building web apps, and it's a constantly shifting landscape where "the way" you do a bunch of things is different every time you start a new app (at least it feels that way to me).
Being really good at front-end (to the point you know when to use a native control or not, which "standard" features you can rely on, how to think about accessibility+responsive+dark mode+ad blockers+low bandwidth+seo etc) is an entire discipline that takes a lot of effort to stay current in.
If you use pure, standard html with default styling you still end up with a page using bad colors and Times New Roman that looks straight out of the 90s. If that's not the look you're going for, you need to do some customization (via CSS) and the difference between "some" and "to the nines" is not exactly a clear line -- even to people that have specialized their careers in front-end dev.
Being really good at front-end (to the point you know when to use a native control or not, which "standard" features you can rely on, how to think about accessibility+responsive+dark mode+ad blockers+low bandwidth+seo etc) is an entire discipline that takes a lot of effort to stay current in.
If you use pure, standard html with default styling you still end up with a page using bad colors and Times New Roman that looks straight out of the 90s. If that's not the look you're going for, you need to do some customization (via CSS) and the difference between "some" and "to the nines" is not exactly a clear line -- even to people that have specialized their careers in front-end dev.
If the decision comes down to "I can't get the exact shade of cornflower blue I want on this button unless I make it a div, but that will hurt accessibility" and you chose the exact shade of cornflower blue, your priorities are wrong. And not just because you hurt accessibility, but because you probably made more work for yourself.
We went through this 15 years ago with custom scroll bars that didn't look like scroll bars, didn't operate like scroll bars and didn't interact like scroll bars, all because it could happen. An Ian Malcom quote comes to mind.
We went through this 15 years ago with custom scroll bars that didn't look like scroll bars, didn't operate like scroll bars and didn't interact like scroll bars, all because it could happen. An Ian Malcom quote comes to mind.
I don't think that's a conscious decision though. What happens is:
- I can't get this exact shade of cornflower blue
- Oh, here's a solution that works! Oh, it doesn't work in all browsers
- Hmm, here's a stack overflow answer that says use a div. It's 5 years old, is that current? Dunno but it has 457 up votes and works
Some people are concerned about accessibility but the JavaScript doesn't work in iOS. Others have iOS support but they screwed up cache headers and it's super slow on any low bandwidth connection.
Balancing all those things (and that's a very incomplete list) is hard and it's not fair to expect side/hobby/oss projects to do it 100%.
- I can't get this exact shade of cornflower blue
- Oh, here's a solution that works! Oh, it doesn't work in all browsers
- Hmm, here's a stack overflow answer that says use a div. It's 5 years old, is that current? Dunno but it has 457 up votes and works
Some people are concerned about accessibility but the JavaScript doesn't work in iOS. Others have iOS support but they screwed up cache headers and it's super slow on any low bandwidth connection.
Balancing all those things (and that's a very incomplete list) is hard and it's not fair to expect side/hobby/oss projects to do it 100%.
Huh? You can get whatever shade you want. Just use a reset stylesheet for buttons and then you can style them like you would any other div. They work in every browser, too. I understand the argument that a decade ago this was trickier, but that time has long since passed. Style your button with css.
iratewizard(1)
[deleted]
Replacing <div class="button "> with <button> is basically zero effort. it's fewer characters and less JS code to construct!
It takes more effort to do it wrong.
How hard is it to just use a damn <button> 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.
I think https://news.ycombinator.com/item?id=25593536 from the larger comment chain said it pretty well. I also just commented something that may be relevant to these thoughts as well https://news.ycombinator.com/item?id=25594659. The child comment by pickpuck is also quite informative.
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).
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).
Perhaps you could open a pull request to fix this.
That would presumably be roughly equivalent to send a PR to translate a single dialog to English when the entire interface is in French.
Sure, if an app is not fully translated and there's a lingering French string somewhere, submit a PR. But in this case, I don't see how this can be a serious suggestion.
Sure, if an app is not fully translated and there's a lingering French string somewhere, submit a PR. But in this case, I don't see how this can be a serious suggestion.
It was a serious suggestion.
By working to understand and solve the problem that seems easy on its surface, either:
1. It ends up harder than it seems. The original poster gains a better understanding of what is preventing the originally proposed solution from working, and is in a better place to judge what needs changing, and generally everyone wins.
2. It ends up as easy as it seems. Not much time is spent, the original poster makes a valuable suggestion in the form of a patch/PR, and generally everyone wins.
By working to understand and solve the problem that seems easy on its surface, either:
1. It ends up harder than it seems. The original poster gains a better understanding of what is preventing the originally proposed solution from working, and is in a better place to judge what needs changing, and generally everyone wins.
2. It ends up as easy as it seems. Not much time is spent, the original poster makes a valuable suggestion in the form of a patch/PR, and generally everyone wins.
I agree with 1 being possible, but if 2 is the case, then this will surely just be scratching the surface and it won't suddenly turn usable by fixing a single div.
The button can't both be an argument that the developer could have easily implemented accessibility and an argument that a it'd be a lot more work to implement accessibility in the same comment chain though.
Unless we're now talking about how to implement buttons for the sake of talking about buttons instead of the accessibility of this project in which case I don't think that's what the PR comment was intended to discuss, rather a PR to fix the actual accessibility issues the project was originally called out for.
I.e. if you think the scope of the should be bigger to address accessibility that doesn't make 2) invalid it just means you think it should be a larger PR.
Unless we're now talking about how to implement buttons for the sake of talking about buttons instead of the accessibility of this project in which case I don't think that's what the PR comment was intended to discuss, rather a PR to fix the actual accessibility issues the project was originally called out for.
I.e. if you think the scope of the should be bigger to address accessibility that doesn't make 2) invalid it just means you think it should be a larger PR.
> The button can't both be an argument that the developer could have easily implemented accessibility and an argument that a it'd be a lot more work to implement accessibility in the same comment chain though.
Sure it can: it'd have been zero extra work if it had been done while writing the code in the first place, but having to do it afterwards means you'd practically have to rewrite the entire thing.
That said, I wouldn't argue that the developer could easily have implemented it, otherwise I'm sure they'd have done so. I'm only lamenting the fact that it wasn't, and that it now can't be solved with a single small PR.
Sure it can: it'd have been zero extra work if it had been done while writing the code in the first place, but having to do it afterwards means you'd practically have to rewrite the entire thing.
That said, I wouldn't argue that the developer could easily have implemented it, otherwise I'm sure they'd have done so. I'm only lamenting the fact that it wasn't, and that it now can't be solved with a single small PR.
Small, positive steps in the right direction are how you get there.
Based on what other commenters have said, it sounds like the button is implemented in a custom react component. In that case ideally it should be as simple as changing the component to output a button instead of a div, with some css to remove the default button styling. Which would be the equivalent of translating a decent chunk of a website to French with one tiny change.
I'd be amazed if the only thing that makes the website inaccessible is the use of a single div instead of a button - that'd be an enormous oversight. As in, there's either a reason for it that does not make this an easy fix, or it's so trivial that it's not a mistake you make if you're the kind of developer that follows basic accessibility practices throughout the rest of the app.
Its usually not an all or nothing thing. Most websites aren't "inaccessible" entirely. They have some parts which work fine in screen readers and some parts which barely work at all, and which leave blind people muddling through. And they can muddle through a lot - blind people don't have much choice a lot of the time.
So incremental improvements like this can still be very helpful. You don't need to fix everything all at once.
So incremental improvements like this can still be very helpful. You don't need to fix everything all at once.
> 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?
Yep as someone who's done a significant amount of front-end development ARIA and accessibility is more billable hours, more time involved into project, and more testing. When it's my own consulting I literally add it as a line-item to the bill and let customers take it off if they want to save cost, and when it's for professional work the only industry that has actual regulation around it is education/government.
Truth is most companies are pushing the cost of development down however they can, and to cater to the accessibility market you're sinking significant dev/testing time into doing it right. Also, you can't blame me in a capitalist society for dropping this on the floor when my customer/employer wants me to... in most situations the hours invested into accessibility will never turn around into profit.
The other problem is I do accessibility right. And most devs don't... I'll actually go through and do UIX experiences on-screen, then replicate it "blind" using a screen reader. This testing/tuning takes real time. Like - I can go through and do best practices with ARIA tags, well thought out HTML5, etc and still it's a total cluster once you actually use the application.
It very much may not be "ignorance/difficult" - looking at what this dev has accomplished with this editor I'm going to give them the benefit of the doubt and say it was just extra time for a tiny fraction of their audience that they haven't invested yet. Harsh reality is they may not have that budget of time to go the extra steps for something as complex as this.
Yep as someone who's done a significant amount of front-end development ARIA and accessibility is more billable hours, more time involved into project, and more testing. When it's my own consulting I literally add it as a line-item to the bill and let customers take it off if they want to save cost, and when it's for professional work the only industry that has actual regulation around it is education/government.
Truth is most companies are pushing the cost of development down however they can, and to cater to the accessibility market you're sinking significant dev/testing time into doing it right. Also, you can't blame me in a capitalist society for dropping this on the floor when my customer/employer wants me to... in most situations the hours invested into accessibility will never turn around into profit.
The other problem is I do accessibility right. And most devs don't... I'll actually go through and do UIX experiences on-screen, then replicate it "blind" using a screen reader. This testing/tuning takes real time. Like - I can go through and do best practices with ARIA tags, well thought out HTML5, etc and still it's a total cluster once you actually use the application.
It very much may not be "ignorance/difficult" - looking at what this dev has accomplished with this editor I'm going to give them the benefit of the doubt and say it was just extra time for a tiny fraction of their audience that they haven't invested yet. Harsh reality is they may not have that budget of time to go the extra steps for something as complex as this.
> I literally add it as a line-item to the bill and let customers take it off if they want to save cost, and when it's for professional work the only industry that has actual regulation around it is education/government.
Take note, the takeaway from this comment is that if you're building a platform for applications and you want to make it accessible, it has to be required. You can't give engineers the choice or they won't do it. They will not prioritize equal access unless either the law or the technology literally forces them to. This kind of stuff is how you get regulated.
This is also why I don't have a ton of sympathy for the people who want to get rid of HTML and use exclusively lower level APIs. They'll tell you they can replicate accessibility features, but they're not going to. They're going to open up the floodgate for interfaces that can't be used with a keyboard. Like, I'm not seriously suggesting this, but maybe divs in HTML shouldn't be clickable at all. Maybe you should be forced to use a button. Maybe the escape hatches that allow people to ignore semantic markup should go away.
I want to live in a world where I can trust developers when they say that the web is for everyone and that equal access is important, and I want to trust them to make educated decisions about what is and isn't possible to make accessible for each project. But if we can't even get people to use buttons instead of divs, if even that turns into some kind of controversy... I don't know, maybe developers shouldn't get to make that choice, maybe the web should force you to use buttons.
The whole point of the web is that it's a universal platform, as much as possible we should be striving to make it universally accessible.
> The other problem is I do accessibility right
We're not talking about something like adding professional captions to every single video you produce or making sure that there are shortcuts to quick-navigate through menus, we're talking about building buttons using the element named "button".
Accessibility isn't binary, we don't have to decide to either do professional testing or to render everything to canvas. It really doesn't take firing up a screenreader to know that a clickable div with no aria roles is not accessible, you don't have to do advanced testing for that.
I'm not going to jump on the shame train for the original author, not everyone knows this stuff and I don't blame the author for making a mistake. I don't expect every web developer to know everything, and shaming people over accidentally breaking accessibility isn't helpful for the cause. Instead we should focus on education and positive reinforcement. We don't want new developers to be scared of accessibility, we want them to feel like we're here to help.
But outside of the original developer, I am absolutely going to jump on the shame train for everyone who's talking about very basic web accessibility features like they're some kind of complicated tradeoff. They're not. Using a button is not hard.
Take note, the takeaway from this comment is that if you're building a platform for applications and you want to make it accessible, it has to be required. You can't give engineers the choice or they won't do it. They will not prioritize equal access unless either the law or the technology literally forces them to. This kind of stuff is how you get regulated.
This is also why I don't have a ton of sympathy for the people who want to get rid of HTML and use exclusively lower level APIs. They'll tell you they can replicate accessibility features, but they're not going to. They're going to open up the floodgate for interfaces that can't be used with a keyboard. Like, I'm not seriously suggesting this, but maybe divs in HTML shouldn't be clickable at all. Maybe you should be forced to use a button. Maybe the escape hatches that allow people to ignore semantic markup should go away.
I want to live in a world where I can trust developers when they say that the web is for everyone and that equal access is important, and I want to trust them to make educated decisions about what is and isn't possible to make accessible for each project. But if we can't even get people to use buttons instead of divs, if even that turns into some kind of controversy... I don't know, maybe developers shouldn't get to make that choice, maybe the web should force you to use buttons.
The whole point of the web is that it's a universal platform, as much as possible we should be striving to make it universally accessible.
> The other problem is I do accessibility right
We're not talking about something like adding professional captions to every single video you produce or making sure that there are shortcuts to quick-navigate through menus, we're talking about building buttons using the element named "button".
Accessibility isn't binary, we don't have to decide to either do professional testing or to render everything to canvas. It really doesn't take firing up a screenreader to know that a clickable div with no aria roles is not accessible, you don't have to do advanced testing for that.
I'm not going to jump on the shame train for the original author, not everyone knows this stuff and I don't blame the author for making a mistake. I don't expect every web developer to know everything, and shaming people over accidentally breaking accessibility isn't helpful for the cause. Instead we should focus on education and positive reinforcement. We don't want new developers to be scared of accessibility, we want them to feel like we're here to help.
But outside of the original developer, I am absolutely going to jump on the shame train for everyone who's talking about very basic web accessibility features like they're some kind of complicated tradeoff. They're not. Using a button is not hard.
>
I want to live in a world where I can trust developers when they say that the web is for everyone and that equal access is important, and I want to trust them to make educated decisions about what is and isn't possible to make accessible for each project. But if we can't even get people to use buttons instead of divs, if even that turns into some kind of controversy... I don't know, maybe developers shouldn't get to make that choice, maybe the web should force you to use buttons.
Most developers only get to make that choice as long as visibility over their work is shitty enough that any time spent on accessibility is lost in the noise.
The button stuff is one of the few things that could (and should) just be done by default, because it doesn't take any extra effort like a lot of accessibility work. But then again, most devs are working in environments where whatever they would just make a plain old button gets loved to death by some design genius with nothing better to do that week and "signed off on" by 15 people before the dev even hears about it. Then they're making a quick decision between throwing accessibility under the bus (and suffering absolutely zero consequences for it) or pissing off literally everyone that has anything to do with their next round of performance reviews.
Most developers only get to make that choice as long as visibility over their work is shitty enough that any time spent on accessibility is lost in the noise.
The button stuff is one of the few things that could (and should) just be done by default, because it doesn't take any extra effort like a lot of accessibility work. But then again, most devs are working in environments where whatever they would just make a plain old button gets loved to death by some design genius with nothing better to do that week and "signed off on" by 15 people before the dev even hears about it. Then they're making a quick decision between throwing accessibility under the bus (and suffering absolutely zero consequences for it) or pissing off literally everyone that has anything to do with their next round of performance reviews.
Right, which is why we need to somewhat entertain the idea that accessibility shouldn't be optional.
In the business environment you're talking about, I'm generally not in favor of legislating things, but maybe that's a requirement here. My point is that assuming what folkhack says is true, then the "we'll just educate people" idea might just not be feasible -- maybe it just straight up requires laws that force businesses to care.
At least for websites in general we can do things outside of the law that force people's hands. Google can deprioritize search results for pages that are inaccessible, but that won't really affect web apps. Maybe there are non-legislative technological penalties we could impose there as well; if there are certain things that only buttons can do, or if browsers start identifying pages/apps that are inaccessible and displaying warnings on them, or locking certain features.
SSL didn't really get solved until browsers started putting a big scary warning next to the URL bar that said the page was insecure. All the education and tooling was helpful, but it wasn't enough to make businesses care until their customers started asking them why Chrome/Firefox was saying that their app was insecure. It's tricky. I don't want the accessibility community to be the villain here, but it does kind of sound like commercial businesses need to be dragged into an accessible world even if they're kicking and screaming about it.
In the business environment you're talking about, I'm generally not in favor of legislating things, but maybe that's a requirement here. My point is that assuming what folkhack says is true, then the "we'll just educate people" idea might just not be feasible -- maybe it just straight up requires laws that force businesses to care.
At least for websites in general we can do things outside of the law that force people's hands. Google can deprioritize search results for pages that are inaccessible, but that won't really affect web apps. Maybe there are non-legislative technological penalties we could impose there as well; if there are certain things that only buttons can do, or if browsers start identifying pages/apps that are inaccessible and displaying warnings on them, or locking certain features.
SSL didn't really get solved until browsers started putting a big scary warning next to the URL bar that said the page was insecure. All the education and tooling was helpful, but it wasn't enough to make businesses care until their customers started asking them why Chrome/Firefox was saying that their app was insecure. It's tricky. I don't want the accessibility community to be the villain here, but it does kind of sound like commercial businesses need to be dragged into an accessible world even if they're kicking and screaming about it.
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.
UI technologies that don't include accessibility are simply not good enough. It's not like accessible options don't exist.
> What does being MIT licensed have to do with it
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.
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.
>It's a non commercial non government project.
Yes I know that, what's that got to do with not having accessibility?
And no it doesn't have to be perfect, it comes down to what we consider acceptable.
Yes I know that, what's that got to do with not having accessibility?
And no it doesn't have to be perfect, it comes down to what we consider acceptable.
I am thankful to the author for not thinking like you, as if they did perhaps there would be no WASM Studio at all as they wouldn't have the time/knowledge/perseverance to continue writing the app far enough to be accessible and perfect for everyone. Luckily, they did the really hard work of getting something that's usable to at least a few of us! And it's been really useful to me as I am trying to write a language targeting WASM.
> Yes I know that, what's that got to do with not having accessibility?
Many (most?) will have different accessibility expectation for software from each of these categories, particularly since in many jurisdictions government and commercial have accessibility laws to follow or expectations on service because of payment/funding. In this case the question is what does accessibility have to do with the project not the other way around and the answer is "whatever people want to contribute to the project" not "what simonh finds acceptable of the project".
> And no it doesn't have to be perfect, it comes down to what we consider acceptable.
But you don't decide what's considered acceptable for someone else's freely available open source software they do. It's also not translated into every language and won't run well on every device. A very large portion of the world can't use it but it's just someone sharing what they've managed to make not someone saying everyone in the world will find the software acceptable or that they owe any functionality out of it to anyone else.
Many (most?) will have different accessibility expectation for software from each of these categories, particularly since in many jurisdictions government and commercial have accessibility laws to follow or expectations on service because of payment/funding. In this case the question is what does accessibility have to do with the project not the other way around and the answer is "whatever people want to contribute to the project" not "what simonh finds acceptable of the project".
> And no it doesn't have to be perfect, it comes down to what we consider acceptable.
But you don't decide what's considered acceptable for someone else's freely available open source software they do. It's also not translated into every language and won't run well on every device. A very large portion of the world can't use it but it's just someone sharing what they've managed to make not someone saying everyone in the world will find the software acceptable or that they owe any functionality out of it to anyone else.
> 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.
Indeed, how dare anyone call you out on demanding that others invest time and effort that you won't.
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)?
> "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)?
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 in this case it may be as simple as using native Buttons, as the above comment said, 'that's as far as I got'. Just pretending that accessibility isn't a significant time an resources doesn't make it any less so. If this wasn't true then there wouldn't be legislation to essentially address this market-failure.
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 in this case it may be as simple as using native Buttons, as the above comment said, 'that's as far as I got'. Just pretending that accessibility isn't a significant time an resources doesn't make it any less so. If this wasn't true then there wouldn't be legislation to essentially address this market-failure.
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 and white.
FWIW, accessibility seems hard. I am not a good web dev, and the conversations that spin out from these accessibility conversations frequently go right over my head. I can build a pretty basic React site, but I have no idea how to add accessibility components to that, or how I would test whether my site is accessible or not.
Part of this problem is probably lack of exposure. I know what a screenreader is, but I don't know how they work. I don't know what makes it easy to traverse a page with a screenreader and what makes it hard. It would probably help a lot if we forced devs to have experience with accessibility tools so they know they work.
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 and white.
FWIW, accessibility seems hard. I am not a good web dev, and the conversations that spin out from these accessibility conversations frequently go right over my head. I can build a pretty basic React site, but I have no idea how to add accessibility components to that, or how I would test whether my site is accessible or not.
Part of this problem is probably lack of exposure. I know what a screenreader is, but I don't know how they work. I don't know what makes it easy to traverse a page with a screenreader and what makes it hard. It would probably help a lot if we forced devs to have experience with accessibility tools so they know they work.
> "FWIW, accessibility seems hard."
Exactly.
Changing <div> to <button>, 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.
Exactly.
Changing <div> to <button>, 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.
[deleted]
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 button slightly differently, etc etc...
Some of this fear may be unfounded or now obsolete but years ago it wasn't fun fixing bugs clients ran into due to silly issues caused by these kinds of things.
Some of this fear may be unfounded or now obsolete but years ago it wasn't fun fixing bugs clients ran into due to silly issues caused by these kinds of things.
Interesting - I would have expected the reverse to be true, i.e. if you often reach for divs first, you'd often be burned by e.g. enter-to-submit not working, or the wrong keyboard showing up on mobile, etc.
The trouble is that it’s users that are burned by this, and only a subset of them, so the developer doesn’t notice unless it affects their particular usage patterns.
But if you have things like “I put my button inside a form, and now when I click on it the page reloads” (because it’s now a submit button, so you need to either change it to type=button or add event.preventDefault() to your click handler or form submit handler, according to taste), that’ll affect everyone, and thus you’ll notice it immediately, and thus it’s you as a developer being burned by it, and so you notice it.
But if you have things like “I put my button inside a form, and now when I click on it the page reloads” (because it’s now a submit button, so you need to either change it to type=button or add event.preventDefault() to your click handler or form submit handler, according to taste), that’ll affect everyone, and thus you’ll notice it immediately, and thus it’s you as a developer being burned by it, and so you notice it.
I see; pretty much the same reason a common problem is that only the happy path works properly - that's the thing for which it's inherent to the development process that it gets tested.
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?
Does anyone know if the web platform now provides a foolproof way to clear all default styling on a button or other standard control?
Yes. This is a good article from CSS Tricks on the subject matter, which describes it all better than I could.
https://css-tricks.com/custom-styling-form-inputs-with-moder...
https://css-tricks.com/custom-styling-form-inputs-with-moder...
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 each combination of OS and browser and user input paradigm. People who rely on muscle memory to use these features, people who perhaps cannot percieve whatever UI hints you come up with to teach your custom control, or people whose needs you have forgotten about, will all struggle to use your UI. And for what? It looks prettier? No thanks.
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 <select> 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.
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.
I don't disagree with this, the main issue I have is that the browser controls are stuck in the 90s/00s: browsers should implement new controls so we have less need for custom work here.
>The browser is the best at doing the things it does, and any control that you implement yourself is going to be worse.
There are plenty of counterexamples.
For example, the date input control does not allow to enforce date format by design, and the auto-detection of user facing format is buggy and inconsistent across browsers on the same system (e.g. Edge legacy ignored Windows' region preference and used the keyboard locale). It tends to show the American-style dates even on non-American locales, making the control not just useless but sometimes actively misleading.
Even apart from that it's pretty basic. Keyboard navigation is bad everywhere bad but in Chrome where it's just mediocre - there's no inline/auto-popup mode like other js pickers, and it requires nonintuitively pressing ENTER to pop-up.
Some browsers like Firefox don't have a 'Today' button, and even in Chrome you can't hide it when it doesn't make sense. No browser has a 'Clear' button which makes sense in some scenarios.
I can go on and on about how flawed that control is, but this is long enough.
There are plenty of counterexamples.
For example, the date input control does not allow to enforce date format by design, and the auto-detection of user facing format is buggy and inconsistent across browsers on the same system (e.g. Edge legacy ignored Windows' region preference and used the keyboard locale). It tends to show the American-style dates even on non-American locales, making the control not just useless but sometimes actively misleading.
Even apart from that it's pretty basic. Keyboard navigation is bad everywhere bad but in Chrome where it's just mediocre - there's no inline/auto-popup mode like other js pickers, and it requires nonintuitively pressing ENTER to pop-up.
Some browsers like Firefox don't have a 'Today' button, and even in Chrome you can't hide it when it doesn't make sense. No browser has a 'Clear' button which makes sense in some scenarios.
I can go on and on about how flawed that control is, but this is long enough.
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 thank yourself for having less code in which something can break. Your users will thank you for already knowing how to use the controls.
An example that drives me crazy is when dropdowns that could have been a select/option group of controls are not. Because most of the time the subtle but insanely helpful keyboard controls are completely missing. Being able to type with the menu selected to jump to items is insanely helpful when the creator insists on jamming too many options into it. Think about that, it’s not exactly trivial to implement, and by the time you have the dozens of lines of JavaScript to implement it correctly... pretty hard not to ask yourself “what the hell am I doing...”
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 thank yourself for having less code in which something can break. Your users will thank you for already knowing how to use the controls.
An example that drives me crazy is when dropdowns that could have been a select/option group of controls are not. Because most of the time the subtle but insanely helpful keyboard controls are completely missing. Being able to type with the menu selected to jump to items is insanely helpful when the creator insists on jamming too many options into it. Think about that, it’s not exactly trivial to implement, and by the time you have the dozens of lines of JavaScript to implement it correctly... pretty hard not to ask yourself “what the hell am I doing...”
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.
"Dropdown with multiselect" is addressed by adding the "multiple" attribute to your select tag. Which has been possible since the 90's.
Nope, per MDN:
> When multiple is specified, most browsers will show a scrolling list box instead of a single line dropdown.
This is not “dropdown with multiselect” because it doesn’t “drop down”
> When multiple is specified, most browsers will show a scrolling list box instead of a single line dropdown.
This is not “dropdown with multiselect” because it doesn’t “drop down”
Tough shit? It does what you want. It doesn't have to look like what you want.
Your extreme stance is not helping the cause. I recognize, for instance, that the HTML select element, with its current limitations, is unsuitable for some real-world use cases. We shouldn't tell application developers that they're wrong to need something more complex than what the NCSA Mosaic team (edit: or maybe Netscape) defined in the 90s. We need to meet developers where they are and make it as easy as possible for them to do the right thing.
Yeah, I do html/css whenever I can: part of the issue is just that html has been neglected compared to css/js over the last ten years or so: the form controls are mostly just what we had in the 90s and they haven’t really developed into a comprehensive set of the controls we need to make applications. It’d be amazing to have something like react-select or a datagrid/Google Sheets-style table as an element but, instead, we mostly are getting CSS and JS improvements, which means that people are going to tend to use divs with CSS/JS for behavior.
It doesn’t do “what I want”, it’s completely unsuitable for most of the use cases I’ve run into. Additionally, this sort of response will never work with a product manager or ux designer.
It's your job as the engineer to tell the product manager or UX designer "no" when they ask you to build interfaces which lock disabled users out of the product. Take some responsibility for the code you write. And if you really cannot use <select multiple>, then have the discipline to read the AIRA guidelines and make sure that whatever you come up with works for everyone.
Not really, the point of having these people is for them to make product and ux decisions. It’s my job to implement the use case they come up with (or quit): I can provide technical advice and suggest easier/better ways to solve their problems but, ultimately, it’s their call.
That's a really shitty way to think about your job. If you don't have the courage to advise your peers (which is what the product manager and UX designer are, your peers), then you aren't worth your salary as an engineer. Thinking for yourself and pushing back against bad designs is part of your job. Do your job.
> "fix this attitude"
I agree with you, hence my first sentence, "guilty of this more often than I should be". I'm much better about using semantic and accessible markup nowadays but I wanted to give some perspective to others who may not be webdevs and are wondering how and why those damn monkeys can screw things up so badly ;)
I agree with you, hence my first sentence, "guilty of this more often than I should be". I'm much better about using semantic and accessible markup nowadays but I wanted to give some perspective to others who may not be webdevs and are wondering how and why those damn monkeys can screw things up so badly ;)
I agree that building an accessible internet should be everyone’s goal, but let’s be real here and assign blame correctly.
The openness of the technology and the internet itself is what killed accessibility for the masses.
Point 1: HTML, assuming an at-least-okay following of semantics, should be accessible by default. Add the planes of JS and CSS though and it’s insanely easy to create non-accessible content.
Point 2: There is no education about accessibility tech. I don’t just mean about how to create accessible content, I mean about the devices themselves. I’m speaking for myself, I hardly know anything about these devices to be honest. Without an idea of how they work, it’s that much harder to keep them in mind when making design considerations.
Point 3: It’s insanely easy to create and host content. With such a low barrier of entry you’re going to get more low quality content. In the real world, there are strict requirements for businesses to make themselves accessible. There is no version of that for web content. Well, for the most part, until you “make it” at which point I believe you CAN actually be fined for having inaccessible web content. Take that with a grain of salt I’m recalling from shaky memory of reading HN comments.
So, what do we do about this? Honestly I think the only thing we CAN do is solve the education part. As children we should be required to be exposed to and educated about these amazing technologies that assist people with disabilities. Because all of us should know, not just us people in the software business (though in this case of course, ESPECIALLY people in the software business)
There is no way to fix the technology stack itself. It’s just been dug into such a deep hole. We can try to add things to it to make building accessible content easier... but that will add to the problem of there already being a million and one different ways of doing the same thing (where a couple of them are accessible)
The openness of the technology and the internet itself is what killed accessibility for the masses.
Point 1: HTML, assuming an at-least-okay following of semantics, should be accessible by default. Add the planes of JS and CSS though and it’s insanely easy to create non-accessible content.
Point 2: There is no education about accessibility tech. I don’t just mean about how to create accessible content, I mean about the devices themselves. I’m speaking for myself, I hardly know anything about these devices to be honest. Without an idea of how they work, it’s that much harder to keep them in mind when making design considerations.
Point 3: It’s insanely easy to create and host content. With such a low barrier of entry you’re going to get more low quality content. In the real world, there are strict requirements for businesses to make themselves accessible. There is no version of that for web content. Well, for the most part, until you “make it” at which point I believe you CAN actually be fined for having inaccessible web content. Take that with a grain of salt I’m recalling from shaky memory of reading HN comments.
So, what do we do about this? Honestly I think the only thing we CAN do is solve the education part. As children we should be required to be exposed to and educated about these amazing technologies that assist people with disabilities. Because all of us should know, not just us people in the software business (though in this case of course, ESPECIALLY people in the software business)
There is no way to fix the technology stack itself. It’s just been dug into such a deep hole. We can try to add things to it to make building accessible content easier... but that will add to the problem of there already being a million and one different ways of doing the same thing (where a couple of them are accessible)
> 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.
This is all a little dramatic, no? It's a cool app that can be easily updated to fix button accessibility.
> It's a cool app that can be easily updated to fix button accessibility.
Well… no, not really, because it’s not just about the buttons. I invariably find that things like this are systemic, so that individual symptoms may be fixed fairly easily, but that there are just lots of basic problems with the markup employed, all of which need to be fixed, and some of which are actually hard to fix because of bad assumptions.
Well… no, not really, because it’s not just about the buttons. I invariably find that things like this are systemic, so that individual symptoms may be fixed fairly easily, but that there are just lots of basic problems with the markup employed, all of which need to be fixed, and some of which are actually hard to fix because of bad assumptions.
Yes, on second thought, that one sentence was probably melodramatic.
> What do we do about this?
https://www.youtube.com/watch?v=DBcz_bGcHgk
After watching this video from Google, I think the future is web components + AOM[1].
This makes sense to me because:
1) Most web developers are already using frameworks (such as React) which can render web components.
2) We can't expect all web developers to be ARIA/WCAG/ADA experts — they're always going to be trying to write code that quickly/efficiently expresses their intent.
Once we get full buy-in and implementation in all browsers and screen readers, most web developers probably won't be using <button> much anymore.
Instead, they'll be using <framework-button>. The <framework-button> sets up all the appropriate ARIA properties/attributes, can restrict what slot content it accepts, and can present remaining issues as errors in the console.
Perhaps under the hood <framework-button> does indeed include a <button> in its Shadow DOM, or maybe it's a <span>.
Coupled with Houdini and some other emerging standards, I think AOM will finally make web components a viable option for most developers, and can solve the vast majority of accessibility issues we see today.
[1]: https://wicg.github.io/aom/explainer.html#motivating-use-cas...
https://www.youtube.com/watch?v=DBcz_bGcHgk
After watching this video from Google, I think the future is web components + AOM[1].
This makes sense to me because:
1) Most web developers are already using frameworks (such as React) which can render web components.
2) We can't expect all web developers to be ARIA/WCAG/ADA experts — they're always going to be trying to write code that quickly/efficiently expresses their intent.
Once we get full buy-in and implementation in all browsers and screen readers, most web developers probably won't be using <button> much anymore.
Instead, they'll be using <framework-button>. The <framework-button> sets up all the appropriate ARIA properties/attributes, can restrict what slot content it accepts, and can present remaining issues as errors in the console.
Perhaps under the hood <framework-button> does indeed include a <button> in its Shadow DOM, or maybe it's a <span>.
Coupled with Houdini and some other emerging standards, I think AOM will finally make web components a viable option for most developers, and can solve the vast majority of accessibility issues we see today.
[1]: https://wicg.github.io/aom/explainer.html#motivating-use-cas...
It's about priorities. Adding accessibility is a feature, just like syntax coloring or debugging. And the reasonable way to prioritize the features is to look at how much effort would it take to implement a feature (and maintain/support it in the long term!) vs. how many new users will it bring.
If you are designing a custom control framework from scratch, supporting accessibility properly is not trivial, and the amount of new users it would bring you pales in comparison with almost any use case-focused feature. So it makes sense that the author would not be willing to implement it.
I also don't like the current approach of arbitrarily targeting small vendors and shaming them into putting unpaid time into a feature that will not pay off for them. It surely gives you the sense of power and moral superiority, but it is extremely toxic and demotivating to small vendors.
I think, a better alternative for people concerned about accessibility would be to offer free help adding accessibility to the products they are concerned about. I am certain, had you approached the author with a ready-to-use pull request instead of calling them ignorant, they would have thanked you and merged your changes into the code base ASAP.
If you are designing a custom control framework from scratch, supporting accessibility properly is not trivial, and the amount of new users it would bring you pales in comparison with almost any use case-focused feature. So it makes sense that the author would not be willing to implement it.
I also don't like the current approach of arbitrarily targeting small vendors and shaming them into putting unpaid time into a feature that will not pay off for them. It surely gives you the sense of power and moral superiority, but it is extremely toxic and demotivating to small vendors.
I think, a better alternative for people concerned about accessibility would be to offer free help adding accessibility to the products they are concerned about. I am certain, had you approached the author with a ready-to-use pull request instead of calling them ignorant, they would have thanked you and merged your changes into the code base ASAP.
Other tools like Vim browser plugins suffer from this issue as
well, making those UI components impossible to interact with.
Meanwhile other sites often have 5 clickable buttons bunched up
within each other or very close together for no reason.
The way many modern sites are frequently built is broken once the user takes a closer look.
The way many modern sites are frequently built is broken once the user takes a closer look.
Jesus F Christ mate... take it easy. You sound like you have been personally attacked. Gathering up the mob and sharpening your pitchfork to tear down someone else's work is easy.
Why don't you start with opening an issue on their Github first? And maybe contribute the code yourself since you feel so strongly about it.
Why don't you start with opening an issue on their Github first? And maybe contribute the code yourself since you feel so strongly about it.
[deleted]
Do development tools really need a11y? I haven't come across anyone with this need before.
There are, in fact, blind programmers, and programmers with other disabilities.
..
You can use the ARIA role="button" attribute [1]. You also should make it focusable using tabindex="0" and allow keyboard input, although some screen readers might be able to get around those limitations...
But like another reply mentioned, you can get it all from free using a normal <button>, which isn't really hard to style even compared to a <div>, and provides it all for free...
[1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
But like another reply mentioned, you can get it all from free using a normal <button>, which isn't really hard to style even compared to a <div>, and provides it all for free...
[1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
I'm sorry if I made you feel that you should be ashamed of your lack of knowledge in this particular area. That wasn't my point at all. I'm just sad that we accessibility advocates have somehow not yet been able to reach you and other developers. I'm sorry you felt the need to retract your comment.
There is some progress though. EmberJS has lint rules to notify the developer when the using a div without role="button" among other things :)
> There should be a way to signal to browser a div will be used for a button or whatever and I believe people would be happy to use such a solution.
That solution already exists: replace "div" with "button"
That solution already exists: replace "div" with "button"
[deleted]
This already exists, and many developers don't use it.
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/
[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.
Anyone have a guess as to when WebAssembly will be able to directly access the DOM?
Despite all the hype, I don't think this will ever realistically happen. interface-types is (supposedly) here but it can't really hold onto DOM objects, it can only reference them, and nobody has made DOM bindings for interface-types yet. GC is an extraordinarily hard problem, and they've talked about scoping out "mini-mini-MVPs" for about a year now, with basically no progress.
I wrote an essay about this a few years ago but never decided to publish it because I felt it was too harsh, but I think it gives a better overview of the challenges involved: https://gist.github.com/magcius/8959ca1f5bbde4bd66b98b6d5dc7...
I wrote an essay about this a few years ago but never decided to publish it because I felt it was too harsh, but I think it gives a better overview of the challenges involved: https://gist.github.com/magcius/8959ca1f5bbde4bd66b98b6d5dc7...
Even if it doesn't happen, at very least it won't be much different from what Google forces upon native devs on Android.
However given the possible security issues, even with a sandbox, maybe that isn't that bad.
However given the possible security issues, even with a sandbox, maybe that isn't that bad.
This is the proposal tracking this: https://github.com/WebAssembly/proposals/issues/16
No recent updates unfortunately.
No recent updates unfortunately.
I love it. Every tool that reduces friction for people to create is a valid effort.
[deleted]
I just get a black screen.
javascript is required, you probably have it disabled (3rd party scripts).
Of course I have 3rd party scripts and iframes disabled.
Go support would be nice
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.
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"
> "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.
Plenty of websites embed JS but work fine with some (or sometimes all) of it disabled.
That would unfortunately be about as useful as the cookie notices - practically every website intentionally or unintentionally includes or references javascript in some way, so the browser would always give the notice.
You thought a web page webasm ide would work without javascript?
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
I thought it was going to be an article about a tool, not a tool itself. I figured it out, but would've appreciated a "This only works with JS" note.
Even if you correctly pick up on the implications of "studio", it could also be a page about WebAssembly Studio or the page where you download it.
No, but NoScript approaches each new site with javascript disabled. You have to manually allow it after you arrive. But when you arrive to a completely blank content area, you may be left wondering if the page simply hasn't completed loading.
Obviously once I realize it has loaded, but it's blank, I assume it's because it requires javascript. So I enable it and reload, and it works as expected.
Obviously once I realize it has loaded, but it's blank, I assume it's because it requires javascript. So I enable it and reload, and it works as expected.
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.