The crazies part is that when we actually research it, a default button is about 20% faster than the the flat nonsense we've settled on (https://www.theregister.com/offbeat/2017/09/05/its-official-...) and nearly a decade letter we still prefer looks over usability.

Imagine everything man-made suddenly disappears but not the knowledge individuals carry. How long until we have an iPhone (or a plastic shirt button)? Would it even be any faster than the first time around?

If you click any link on this page (to the author’s site) and you dare to use an alternative browser on iOS, it shows a full page modal that can only be navigated around by clicking an “escape” button which tries to execute a Siri shortcut. Apparently in-app browsers are a threat to user freedom, but Orion is caught in the dragnet. Perhaps an example of the paternalist approach to development on the web gone wrong.

I now have a more critical eye and look into potential UI components code to decide if it really does need the custom code or if styling alone can get the job done.

Shoelace upending everything to Web Awesome has given me an incentive to revisit this rather then blindly find/replacing all the sl- prefixes to wa- given how much larger it makes my bundle.

The day after the lawsuit was filed, a company specializing in accessibility testing mysteriously contacted the client, offering a solution. Client had not even gotten notice of the litigation yet.

The net result of this was several tens of thousands of dollars spent actually removing Aria tags and using standard modern HTML on their aging website, to barely meet some threshold that appeared to be compliant.

The company who did the "work", and I mean, it was barely any work, maybe 100 LoC, stands by it and says the client won't get sued again, as long as they pay for ongoing compliance testing. So it's all a fucking racket.

I pointed out to the client that I didn't think that this half-assed effort was remotely sufficient to actually improve accessibility, but they had an interesting response. Which was this:

In 3 years, all this compliance shit will be out the window, because AI screen readers and agents are going to make the whole point moot.

I can't really disagree with that.

I think that emphasizes the point though. You need more code to do it correctly.

The implementation assumes that onpointerup is mutually exclusive to the other two, but it fires in addition to mouse/touch events. Only onpointerup is needed, if you include onmouseup and ontouchstart then the button action will fire twice.

However, you also need an onpointerdown handler to verify that the pointer press started inside the button. Without it, the button would activate if you started holding down the mouse button outside the button area, and then releasing inside the button area.

class SaganButton extends HTMLButtonElement { … }

Anyone know the reasoning they’re blocking this?

https://youtu.be/xE9W9Ghe4Jk?is=wmaIJ6LXNW-mZ49Q