> 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.
(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.
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?
Is there any resources pointing to such best practices and/or accessibility?
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 might be missing something, how would it have been easier to make by adding additional ARIA markup to the UI?
Things to read:
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.
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.
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.
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."
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.
> 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.
Thank you. I'm embarrassed at how melodramatic that part of my original comment was, but I'm glad someone gets it.
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
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?
• 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.
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.
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.
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 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 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.
Businesses should choose to make their business accessible based on cost and profitability. Your eternal vigilance is a joke. It makes sane people wonder what shortcoming you're compensating for.
I believe its worth burning some of society's resources inefficiently in exchange for evening out the scales of chance a little. Its the same reason I think everyone has a right to free healthcare. (Which is completely non-controversial here in australia.)
Call me names all day if you need to. I stand by my politics.
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).
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.
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.
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.
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.
So incremental improvements like this can still be very helpful. You don't need to fix everything all at once.
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.
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.
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.
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.
UI technologies that don't include accessibility are simply not good enough. It's not like accessible options don't exist.
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.
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.
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.
Indeed, how dare anyone call you out on demanding that others invest time and effort that you won't.
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.