[ivraatiems]

I so frequently see this tone with accessibility discussions: "X is not accessible, so don't use it, stop what you're doing, this is bad." I don't think that kind of scolding - which is what it comes off as - is productive for solving the problem of "X is not accessible", because it presumes the problem is unfixable. I believe you wrote your comment in good faith, and I agree accessibility is important. But I think you should consider focusing on this:

> I'm sure there are ways to add accessibility to a web port of WX

and not

> Just uttering my careful warning that you should please, please, please think 3, 4, 5 times before deciding to actually use this UI library for serious projects.

because, as you acknowledge, this is a hobby project. The goal is to do something cool and fun and push boundaries of what's possible. So if pushing accessibility for all web apps is your goal, why not seize this moment to say "hey let's find ways to make WASM apps more accessible" rather than saying "nobody should use this for serious projects"? Why not try to fix it rather than shutting it down? Doesn't it benefit people more if we find a way to make accessibility easy, rather than discouraging people because it's hard?

There are lots of cool and interesting technical problems in there that somebody who takes the time to make something like this could have interest in: How do OCR or other accessibility tools understand canvasses? How can we communicate with them? What addons to WASM or wxWidgets would achieve this goal?

[mwcampbell]

> I don't think that kind of scolding - which is what it comes off as - is productive for solving the problem of "X is not accessible", because it presumes the problem is unfixable.

Of course the problem is fixable. But in the meantime, until it's fixed, a disabled person could fail to get a particular job, or even lose a job they already have, due to an inaccessible application. It's important to remember that the stakes are really that high. If we want to prevent that from happening, I think it's worthwhile to try to persuade application developers to not use inaccessible GUI toolkits, particularly for new projects. We can do that at the same time that we work on making more GUIs accessible.

[ivraatiems]

> I think it's worthwhile to try to persuade application developers to not use inaccessible GUI toolkits, particularly for new projects. We can do that at the same time that we work on making more GUIs accessible.

Can we? People don't typically work on tools they don't intend to use. Where are the people doing the fixing going to come from if the conventional wisdom is "even if you use this for a side project, you're harming disabled people?"

Another way of framing your suggestion here is that toolkits with the resources to make themselves accessible without community help will always dominate toolkits that don't have those resources. That stifles progress for anyone.

> But in the meantime, until it's fixed, a disabled person could fail to get a particular job, or even lose a job they already have, due to an inaccessible application.

This kind of stake-raising honestly feels toxic to me, sometimes. You can make the same argument about almost anything. Eventually, you're going to get tuned out, because the knee-jerk reaction expressed to any new project is "well, you didn't do thing X I wanted, so I refuse to care even if the project has merit."

What's wrong with saying "hey, this is cool, but be aware if you wanna use wxWidgets for production app, know it's inaccessible and so you'll have more work to do to make your app accessible, which I assume you want to do, because it's the right (and often profitable!) thing to do"?

Why do we have to escalate it to "If you make side projects with wxWidgets, you're encouraging people to use them for production apps and therefore causing disabled people to lose their jobs"? It's purposefully taking everything in the most negative way possible.

Put another way, how is your argument distinct from the following: "Working on Audacity, a project for audio, privileges hearing people over Deaf people, and therefore could deprive Deaf people of programming jobs would go to text-based projects if there were fewer commercial audio engineering products helping people to replace text resources (blogs, etc.) with audio (podcasts, etc.). Therefore, Audacity is harmful and one should not work on it."

[Eduard]

> I so frequently see this tone with accessibility discussions: "X is not accessible, so don't use it, stop what you're doing, this is bad."

'Don't use X for reasons ABC' is a great advice! Why use unusable X if some other thing Y works?

Have you tried using Wavvy on a smartphone? Guess what: it's effectively unusable on smartphones: - touch events aren't leveraged. - hover and right click aren't available, and keyboard shortcuts don't have an appropriate substitute; therefore core audio editing tasks cannot be accomplished in any acceptable manner.

If you are accustomed as I am to use Audacity on a desktop PC - clicking, cutting, shortcutting your sound files effortlessly - but then use Wavvy for the first time, you gonna feel...

disabled.

And that's only a glimpse into what the experience must be for a blind person using Wavvy. Here is an experiment: Close your eyes, use Wavvy. Only OCR allowed...

Being an awesome POC, the accessibility issues aren't Wavvy's "fault", but wxwidget's (and Audacity's by depending on wxwidget).

Considering audio is especially valuable for visually impaired people, having a usable audio editor is very valuable.

Now imagine, as it's so often the case in IT, everybody jumps on the latest bandwagon ("Docker all the things!", "Electron all the things!"), and suddenly everybody "WASM-canvases all the things!".

Now imagine Audacity decides "WASM-canvas" is the way to go for Audacity distribution; no more separate builds for Windows, Linux, macOS, just one WASM-canvas build.

And so do other software projects. And so does your company with its IT department software contribution... more and more, you cannot do your tasks the way you used to...

Back to the comment: constructive critique is always helpful:

- It helps Wavvy to consider using an alternative audio editor. - It helps Audacity to improve their usability and accessibility and consider another widget provider. - It helps wxwidget to fix their accessibility shortcomings.

We discuss problematic tools, libraries, websites, and services all the time at HN - be it for privacy concerns, performance issues and whatnot. We all learn from that why e.g. having a slice of privacy is also a good thing for us personally. So is accessibility, even when it's just the slices involving good layouts, readable fonts, unconfusing button naming, logical tabbing order, consistent shortcuts across applications, big-enough advertising close buttons, unfrustating timepickers... , ..., ...

> I don't think that kind of scolding - which is what it comes off as - is productive for solving the problem of "X is not accessible"...

ClawsOnPaws is neither scolding, nor is it coming off as it for me. They apologize upfront, says "please, please, please", says "my aim is not to discourage anyone from trying out new things".

If there was one polite, constructive comment at HN it be it.

> ...because it presumes the problem is unfixable.

I don't understand how you came to the conclusion that this was even remotely implied.

> But I think you should consider focusing on this: "I'm sure there are ways to add accessibility to a web port of WX"

I think you should consider focusing on this: "I'm sure wxwidgets could follow basic accessibility best practices and leverage accessibility APIs which are provided by operating systems already for years."

> why not seize this moment to say "hey let's find ways to make WASM apps more accessible"

I'm not an WASM expert, but I'm versed in accessibility features specified by W3C and implemented in browsers. As WASM can interact with Javascript, and Javascript allows all kinds of web accessibility standards interactions, this part is solved. What's required then is a mapping from OS accessibility calls (wxwidgets' duty) to browserland (WASM's side). I don't know about WASM's status here, but wxwidgets will have to make its own first step. ...

ClawsOnPaws' comment is a tangent comment on an important aspect of any application: usability. It gives awesome insights about why Wavvy is unusable for visually-impaired users.

- I learned that Audacity has its own problems with accessibility; - I learned that Audacity uses wxWidgets, which especially is bad when it comes to accessibility. That already is great to know, as I'm now informed to avoid it in my projects - with bad accessibility always comes a generally bad usability. - Now port this to the web as in the currently presented Wavvy form and you get a hilarious clusterfuck of inaccessibility. I learned from the comment that usability by default and without explicit consideration just degrates with each layer added and each porting. - useful information that there exists some OCR software for what's currently shown on the screen.

In essence, ClawsOnPaws' comment has everything in it for why I come to Hacker News.

[ivraatiems]

I don't have time now to reply to everything in here; there's a lot. But I did want to mention that I posted some thoughts about WASM accessibility here: https://news.ycombinator.com/context?id=32697514 which are hopefully valuable in terms of how the problem could be solved without rewriting a given target application.

With regards to the rest, suffice it to say that I don't find the slippery slope argument persuasive. Given, though, that we're mostly arguing about how to approach doing the thing we both agree should be done, figured I might try and think about things that actually achieve the goal instead.