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.
By working to understand and solve the problem that seems easy on its surface, either:
1. It ends up harder than it seems. The original poster gains a better understanding of what is preventing the originally proposed solution from working, and is in a better place to judge what needs changing, and generally everyone wins.
2. It ends up as easy as it seems. Not much time is spent, the original poster makes a valuable suggestion in the form of a patch/PR, and generally everyone wins.
I agree with 1 being possible, but if 2 is the case, then this will surely just be scratching the surface and it won't suddenly turn usable by fixing a single div.
The button can't both be an argument that the developer could have easily implemented accessibility and an argument that a it'd be a lot more work to implement accessibility in the same comment chain though.
Unless we're now talking about how to implement buttons for the sake of talking about buttons instead of the accessibility of this project in which case I don't think that's what the PR comment was intended to discuss, rather a PR to fix the actual accessibility issues the project was originally called out for.
I.e. if you think the scope of the should be bigger to address accessibility that doesn't make 2) invalid it just means you think it should be a larger PR.
> The button can't both be an argument that the developer could have easily implemented accessibility and an argument that a it'd be a lot more work to implement accessibility in the same comment chain though.
Sure it can: it'd have been zero extra work if it had been done while writing the code in the first place, but having to do it afterwards means you'd practically have to rewrite the entire thing.
That said, I wouldn't argue that the developer could easily have implemented it, otherwise I'm sure they'd have done so. I'm only lamenting the fact that it wasn't, and that it now can't be solved with a single small PR.
Based on what other commenters have said, it sounds like the button is implemented in a custom react component. In that case ideally it should be as simple as changing the component to output a button instead of a div, with some css to remove the default button styling. Which would be the equivalent of translating a decent chunk of a website to French with one tiny change.
I'd be amazed if the only thing that makes the website inaccessible is the use of a single div instead of a button - that'd be an enormous oversight. As in, there's either a reason for it that does not make this an easy fix, or it's so trivial that it's not a mistake you make if you're the kind of developer that follows basic accessibility practices throughout the rest of the app.
Its usually not an all or nothing thing. Most websites aren't "inaccessible" entirely. They have some parts which work fine in screen readers and some parts which barely work at all, and which leave blind people muddling through. And they can muddle through a lot - blind people don't have much choice a lot of the time.
So incremental improvements like this can still be very helpful. You don't need to fix everything all at once.
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.