[HN Gopher] WebAssembly Studio
___________________________________________________________________
WebAssembly Studio
Author : joubert
Score : 292 points
Date : 2020-12-31 13:31 UTC (9 hours ago)
(HTM) web link (webassembly.studio)
(TXT) w3m dump (webassembly.studio)
| bavell wrote:
| 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.
| andrew_ wrote:
| 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.
| halfmatthalfcat wrote:
| 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.
| bamboleo wrote:
| 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.
| k__ wrote:
| 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.
| bavell wrote:
| 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.
| k__ wrote:
| Today, I would probably choose something higher level than
| meddling around with Webpack directly.
| hombre_fatal wrote:
| 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.
| k__ wrote:
| I was thinking about more integrated solutions like
| Next.js or Expo.
| bavell wrote:
| 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.
| gravypod wrote:
| 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.
| [deleted]
| skrebbel wrote:
| Something similar but also totally different is
| https://makepad.nl/ - a graphics programming IDE in Rust, for
| Rust, targeting the browser.
|
| 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.
| pjmlp wrote:
| Interesting, thanks for sharing.
| bestinterest wrote:
| Is it just me that finds all the text rendering on this page
| really bad?
| sgzfx wrote:
| 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.
| Alexendoo wrote:
| Everything is rendered directly to a canvas, at the very
| least it lacks subpixel rendering
| [deleted]
| imaginenore wrote:
| I open the "Hello World" project in C.
|
| I change printf("Hello World\n");
|
| to printf("Hello Worlds\n");
|
| I build and run, still outputs "Hello World".
|
| I delete main.wasm, build and run again, still outputs "Hello
| World".
| pjmlp wrote:
| 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.
| Kyro38 wrote:
| Yep, it's not actively developed :
| https://github.com/wasdk/WebAssemblyStudio/commits/master
| chrisweekly wrote:
| Bummer. Seemed like a decent tool, too. :/
| blunte wrote:
| 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.
| dboreham wrote:
| Perhaps a missing browser feature?
|
| "You loaded a page with JS but you also disabled JS execution,
| so it probably won't work"
| yjftsjthsd-h wrote:
| > "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.
| CyberDildonics wrote:
| You thought a web page webasm ide would work without
| javascript?
| blunte wrote:
| 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.
| mrspeaker wrote:
| 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)
| CyberDildonics wrote:
| The url is webassembly.studio and the title is WebAssembly
| Studio
| Shared404 wrote:
| 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.
| Dylan16807 wrote:
| 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.
| themihai wrote:
| Go support would be nice
| dr-detroit wrote:
| Meme technology invented for snowflakes who insist react and
| angular are replaced by new frameworks every month and therefore
| web development should resemble 1980s computer science class.
| intrasight wrote:
| I just get a black screen.
| htk wrote:
| I love it. Every tool that reduces friction for people to create
| is a valid effort.
| iKlsR wrote:
| 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/
| rikkus wrote:
| 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.
| chrisweekly wrote:
| Question for anyone with real WASM experience: what are your top
| recommended entry points / reference materials? AssemblyScript
| seems pretty approachable at 1st glance...
| dboreham wrote:
| I've played around with Haskell via the Asteruis project :
| https://github.com/tweag/asterius
|
| Also emscripten of course, for C/C++.
| the_duke wrote:
| 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.
| McGlockenshire wrote:
| > 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.
| pjmlp wrote:
| 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.
| benjaminjackman wrote:
| > 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.
| pjmlp wrote:
| 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.
| yodalf wrote:
| 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.
| tom_mellior wrote:
| 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".
| tomasreimers wrote:
| 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?
| colesantiago wrote:
| Shopify is using WASM in production [0]
|
| [0] https://shopify.engineering/shopify-webassembly
| suprfsat wrote:
| Google Duo's web client has some wasm code cached under the
| name 'wasm-clips'.
| texodus wrote:
| Perspective is developed at JPMorgan
| https://github.com/finos/perspective/
| pjmlp wrote:
| 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/
| Yuioup wrote:
| The 90s called. They want their RAD tools back.
| paulgb wrote:
| 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.
| tomphoolery wrote:
| what about https://www.animaapp.com/ ?
| sbarre wrote:
| 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?
| zo1 wrote:
| 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+...
| konaraddi wrote:
| 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...
| austincummings wrote:
| Twitch also appears to be using it, although I don't know what
| for.
| maxgraey wrote:
| There site which aggregate prod use cases:
| https://madewithwebassembly.com/
| jayflux wrote:
| 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
| maxgraey wrote:
| Ruffle - A Flash Player emulator over WebAssembly:
| https://github.com/ruffle-rs/ruffle
| TazeTSchnitzel wrote:
| Unity, the very popular 3D game engine, can "export" games to
| run in the browser. WebAssembly is undoubtedly involved.
| echeese wrote:
| Google Earth: https://earth.google.com/web/
| kowsheek wrote:
| 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
| brundolf wrote:
| 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.
| postalrat wrote:
| 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.
| brundolf wrote:
| 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.
| arconis987 wrote:
| 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/
| stopyellingatme wrote:
| Figma is an actual tool, written for the web. Lots of great
| engineering happening over there.
| dboreham wrote:
| 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.
| novok wrote:
| It starts immediately, while any embedded java applet took
| forever and looked really ugly. We've also done this with
| flash apps
| TheRealPomax wrote:
| 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.
| worik wrote:
| Unless your user is using a iPhone.
| austincummings wrote:
| Safari has support for WebAssembly.
| tadfisher wrote:
| 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.
| WalterGR wrote:
| > 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.
| codeflo wrote:
| 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.
| Closi wrote:
| Can't we just do this in sandboxed regular assembly
| running inside a virtual machine?!
|
| /s
| codeflo wrote:
| 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?
| brabel wrote:
| 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).
| [deleted]
| taivare wrote:
| Anyone have a guess as to when WebAssembly will be able to
| directly access the DOM?
| Jasper_ wrote:
| 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...
| city41 wrote:
| This is the proposal tracking this:
| https://github.com/WebAssembly/proposals/issues/16
|
| No recent updates unfortunately.
| mwcampbell wrote:
| 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?
| k4rli wrote:
| Do development tools really need a11y? I haven't come across
| anyone with this need before.
| mwcampbell wrote:
| There are, in fact, blind programmers, and programmers with
| other disabilities.
| clickness wrote:
| 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)?
| [deleted]
| joshjhargreaves wrote:
| 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.
| curryst wrote:
| 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.
| clickness wrote:
| > "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.
| corytheboyd wrote:
| 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)
| CyberDildonics wrote:
| There is a github link at he top right, you could start there.
| mwcampbell wrote:
| I was talking about the general problem of new inaccessible
| apps being developed, not this specific project.
| skrebbel wrote:
| What do you think is a good starting point for developers
| who want to get better at this?
|
| For example, do you know of a good way for developers with
| no disabilities to get an impression of how a site works in
| various screen readers?
| spicybright wrote:
| The accessibility mode in the firefox debugger is a good
| start.
| skrebbel wrote:
| Wow nice! I feel pretty stupid for just having looked
| over that all the time. It comes pretty close to what I
| hoped to get.
|
| I do see some surprising behavior though, eg I ran it on
| WhatsApp Web, where it complains about image links that
| have no `alt`. But these links do have a `title`.
| Wouldn't every screen reader fall back to the `title`
| when there's no `alt`? What I mean is, is that an actual
| issue or just a "satisfy the tool" level thing to fix?
| I'm not sure how people build up an intuition for stuff
| like this, any suggestions?
| crisnoble wrote:
| If you are using a mac, try using the web for a few
| minutes with the built in screen reader turned on. It is
| actually pretty fun, and definitely helps get a feel for
| what a non sighted user would be dealing with. Your
| example with alt is a good one, but they should still
| have an empty alt if it is not needed/applicable. Here is
| an intro to voiceover
| https://webaim.org/articles/voiceover/
| abellerose wrote:
| ..
| ratww wrote:
| 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...
| scotth wrote:
| I mean, this is exactly what aria attributes are for, right?
| [deleted]
| detaro wrote:
| This already exists, and many developers don't use it.
| Nicksil wrote:
| > 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"
| [deleted]
| mwcampbell wrote:
| 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.
| aspaviento wrote:
| There is some progress though. EmberJS has lint rules to
| notify the developer when the using a div without
| role="button" among other things :)
| drevil-v2 wrote:
| 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.
| david_dan wrote:
| All the greatest products/services in the world started
| targeting the healthy, the rich, or the white.
|
| May be a11y, l10n are the premature optimization equivalent of
| product design?
| cassetti wrote:
| > 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.
| chrismorgan wrote:
| > _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.
| mwcampbell wrote:
| Yes, on second thought, that one sentence was probably
| melodramatic.
| pickpuck wrote:
| > 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...
| bavell wrote:
| 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.
| ddevault wrote:
| 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.
| chrismorgan wrote:
| 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.
| fiddlerwoaroof wrote:
| 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.
| corytheboyd wrote:
| 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..."
| fiddlerwoaroof wrote:
| 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.
| ddevault wrote:
| "Dropdown with multiselect" is addressed by adding the
| "multiple" attribute to your select tag. Which has been
| possible since the 90's.
| fiddlerwoaroof wrote:
| 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"
| ddevault wrote:
| Tough shit? It does what you want. It doesn't have to
| look like what you want.
| mwcampbell wrote:
| 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.
| fiddlerwoaroof wrote:
| 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.
| fiddlerwoaroof wrote:
| 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.
| ddevault wrote:
| 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.
| fiddlerwoaroof wrote:
| 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.
| ddevault wrote:
| 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.
| mwcampbell wrote:
| 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?
| no_wizard wrote:
| 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...
| crisnoble wrote:
| `appearance: none;` gets you a long way
| plussed_reader wrote:
| But muh ableist design preferences....
| mwcampbell wrote:
| Please avoid this kind of unconstructive snark. I'm prone
| to it myself when discussing this subject, but I try to
| avoid it when discussing accessibility with a broad
| audience like HN. I want to meet mainstream developers
| where they are, figure out what prevents them from making
| their applications accessible, and do something about it,
| not just guilt-trip them.
| crisnoble wrote:
| I actually use <button> with appearance:none specifically
| for accessibility. You get all of the benefits of a
| button's accessibility, focus, click events, normal
| tabbing, etc, and can use them for things like toggling
| an accordion of content or showing/hiding a mobile menu.
| Better than a div because you don't need aria-role, and
| better than a link because it is not taking you anywhere.
|
| As pointed out up thread, developers and designers often
| skip using <button> because it is hard to style just
| right. Using appearance:none resets the style but not the
| accessibility behavior.
| Vinnl wrote:
| 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.
| chrismorgan wrote:
| 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.
| zamadatix wrote:
| 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.
| ddevault wrote:
| 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.
| zamadatix wrote:
| 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?
| pegasus wrote:
| They could have just used off-the-shelf components for
| the first iteration.
| zamadatix wrote:
| 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.
| xingyzt wrote:
| The clickable divs should be focusable and have the aria
| button role. <div tabindex="0" role="button">...</div>
| chrismorgan wrote:
| 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
| zamadatix wrote:
| Agreed they should to have accessibility support.
| ddevault wrote:
| 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.
| zamadatix wrote:
| 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.
| danShumway wrote:
| > 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:
| border: none;
|
| And the button looks exactly the same as the div, except
| now it's visually focusable and accessible. Same is true
| in Chrome. And those are likely the only two rendering
| engines that the original developer cares about, it's not
| like IE11 is worth supporting for a WASM IDE.
|
| No bikeshedding needed here, I didn't even need to look
| up a button reset style.
| jablan wrote:
| How do you know what styling the project needed? What
| styling requires a button to stop being a button?
| folkhack wrote:
| > 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.
| danShumway wrote:
| > 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_.
| pickpuck wrote:
| > > 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.
| chrismorgan wrote:
| 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.
| Stratoscope wrote:
| > _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?
| wffurr wrote:
| 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.
| rhencke wrote:
| Perhaps you could open a pull request to fix this.
| Vinnl wrote:
| 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.
| josephg wrote:
| 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.
| rhencke wrote:
| 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.
| zamadatix wrote:
| 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).
| simonh wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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.
| zamadatix wrote:
| > 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.
| simonh wrote:
| >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.
| brabel wrote:
| 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.
| zamadatix wrote:
| > 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.
| spicybright wrote:
| 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.
| thwarted wrote:
| 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.
| Wowfunhappy wrote:
| 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.
| iratewizard wrote:
| I don't understand this entitled attitude. The OP can
| build things however they want. If their style of
| building makes it hard for the 0.05% of internet traffic
| that uses a screen reader, it's not open season to be a
| shitty person. If I were the OP and received feedback
| like this, I'd personally start aria describing how you
| all need a better mix of anti-anxiety and
| antidepressants.
| josephg wrote:
| Do you think buildings shouldn't be wheelchair
| accessible, because not many people are wheelchair bound?
| Most western societies have made the decision culturally
| that even though its disproportionately expensive, that
| the cost is worth spending to (as much as is reasonable)
| make things accessible. (Legislators are on board in many
| countries too.)
|
| I see your point - this website is really cool and its
| classic HN to have the top comment complain about a minor
| point. But also, because accessibility and security are
| invisible to most of us, vigilance is the only way it'll
| happen.
| gregmac wrote:
| 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.
| thwarted wrote:
| 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.
| gregmac wrote:
| 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%.
| josephg wrote:
| 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.
| [deleted]
| kevingadd wrote:
| Replacing <div class="button "> with <button> is basically
| zero effort. it's fewer characters and less JS code to
| construct!
| alpaca128 wrote:
| 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.
| [deleted]
| hobby-coder-guy wrote:
| "Hey, here are some tips on making your site more accessible"
___________________________________________________________________
(page generated 2020-12-31 23:00 UTC)