211–220 of 231 posts
Earlier quoted context omitted.
> And you can say what you want, the thing is damn snappy. It's horribly slow on my computer, animations and scrolling happen at like 5fps. It also sends my cpu usage through the roof.
You have to activate hardware acceleration. And it will be the snappiest you ever saw.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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.
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 ori…
Earlier quoted context omitted.
Interesting - I would have expected the reverse to be true, i.e. if you often reach for divs first, you'd often be burned by e.g. enter-to-submit not working, or the wrong keyboard showing up on mobile, etc.
The trouble is that it’s users that are burned by this, and only a subset of them, so the developer doesn’t notice unless it affects their particular usage patterns. But if you have things like “I put my button inside a form, and now when I click on it the page reloads” (because it’s now a submit button, so you need to either change it to type=button or add event.preventDefault() to your click handler or form submit…
Question for anyone with real WASM experience: what are your top recommended entry points / reference materials? AssemblyScript seems pretty approachable at 1st glance...
Earlier quoted context omitted.
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…
> 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 be…
Is there any resources pointing to such best practices and/or accessibility?
Earlier quoted context omitted.
https://i.imgur.com/ztxBRHP.png Since somehow we're still talking about how to do it I'd simply do "all: unset" if I don't care about IE and want to fully control the style. In that way the defaults go out the window and I can build up to the style I want. If you don't do this approach you're going to want to keep in mind differences in default whitespace handling and alignment/sizing model defaults which are going t…
I'm not sure what to say about your image other than that you are not setting styles the same way I am, because that doesn't happen when I make those changes. I'm not sure what the difference is, maybe there's something special about the platform you're on that doesn't show up on my desktop computer. In either case, adjust the bottom margin by -1 pixel and move on with your life. > the assumption is the developer is…
Thank you. I'm embarrassed at how melodramatic that part of my original comment was, but I'm glad someone gets it.
Earlier quoted context omitted.
https://i.imgur.com/ztxBRHP.png Since somehow we're still talking about how to do it I'd simply do "all: unset" if I don't care about IE and want to fully control the style. In that way the defaults go out the window and I can build up to the style I want. If you don't do this approach you're going to want to keep in mind differences in default whitespace handling and alignment/sizing model defaults which are going t…
I'm not sure what to say about your image other than that you are not setting styles the same way I am, because that doesn't happen when I make those changes. I'm not sure what the difference is, maybe there's something special about the platform you're on that doesn't show up on my desktop computer. In either case, adjust the bottom margin by -1 pixel and move on with your life. > the assumption is the developer is…
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
Earlier quoted context omitted.
Everything is rendered directly to a canvas, at the very least it lacks subpixel rendering
For those wondering why: subpixel rendering requires knowing the subpixel layout of the display. It’s something your OS knows, but your web browser doesn’t tell the website.
Earlier quoted context omitted.
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 ori…
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.