For years, advocates for web standards, performance, and accessibility have implored web developers to “use the platform”. I’ve often been one of those…
Many (most) developers are not power users and they don’t see the depth of what the platform provides and what they lose by rolling their own implementation. To give a few examples:
middle-clicking a link to open it in a new tab (doesn’t work with most JS-based “links”)
keyboard navigation (Alt+<letter> shortcuts in menus, tab order, typing in dropdowns,…)
Especially on the web, some platform components are still somewhat broken (e.g., date pickers) or missing (e.g., why is there no browser component for an image gallery and instead every website has its own creatively broken half unusable version? same for rich text editing).
It’s a good point, yeah. I think in my “dialog” example a common case would be that the JS developer builds something that works well enough for sighted mouse users and then completely ignores all the stuff you’re supposed to do for keyboard or screenreader users.
I think some of it also comes from React component libraries not having the proper affordances/idioms to easily swap in a link for a button or vice versa. So you reach for a button to do a link’s job and then break a bunch of stuff like right-click, middle-click, etc.
OTOH I’ve also seen cases where the React library did have the proper idioms, and the problem is that the developer didn’t know to use them! For example at my work we use Chakra UI which I’ve found has excellent accessibility, but only if you use it exactly as documented. (Arguably this is another case of “not understanding the platform.”)
Two comments… one, when people say like <select> looks wrong (something btw that isn’t the case anymore like it used to be), I point out that compromises are always made. Often, people compromise on the accessibility or nojs or whatever minority case instead of the visual bits the majority sees, but fact is they do compromise on requirements and sometimes you can convince them to shift which compromises they make in favor of using the platform instead of the alternatives.
Second comment on links and buttons, it occurred to me a little while ago that every link is a button, but not every button is a link. Specifically, every link is conceptually a submit button on a little GET form, with action of the href url. I think it is kinda useful to realize this to help with a conceptual model (actually, why can’t you submit any form to a new window? they really should be more interchangeable than they currently are), but the link is also quite specialized out of the box and it is the specializations that give the attention to detail that makes a UI pleasant to use.
I think my advice (and I want to write a tutorial someday, like web from first principles, but who has the time) would be to realize the general concept then go to the most specialized thing the platform offers that still fits, and then go ahead and specialize it a bit more with your css/script. When doing a thing, ask: What is it? What does it do? What does it look like? in that order and go from there. But “what is it?” is a kinda deep philosophical question that is easy to beget lol
I suspect there are a few more aspects:
score 1 · canonical
It’s a good point, yeah. I think in my “dialog” example a common case would be that the JS developer builds something that works well enough for sighted mouse users and then completely ignores all the stuff you’re supposed to do for keyboard or screenreader users.
I think some of it also comes from React component libraries not having the proper affordances/idioms to easily swap in a link for a button or vice versa. So you reach for a button to do a link’s job and then break a bunch of stuff like right-click, middle-click, etc.
OTOH I’ve also seen cases where the React library did have the proper idioms, and the problem is that the developer didn’t know to use them! For example at my work we use Chakra UI which I’ve found has excellent accessibility, but only if you use it exactly as documented. (Arguably this is another case of “not understanding the platform.”)
score 1 · canonical
Two comments… one, when people say like
<select>looks wrong (something btw that isn’t the case anymore like it used to be), I point out that compromises are always made. Often, people compromise on the accessibility or nojs or whatever minority case instead of the visual bits the majority sees, but fact is they do compromise on requirements and sometimes you can convince them to shift which compromises they make in favor of using the platform instead of the alternatives.Second comment on links and buttons, it occurred to me a little while ago that every link is a button, but not every button is a link. Specifically, every link is conceptually a submit button on a little GET form, with action of the href url. I think it is kinda useful to realize this to help with a conceptual model (actually, why can’t you submit any form to a new window? they really should be more interchangeable than they currently are), but the link is also quite specialized out of the box and it is the specializations that give the attention to detail that makes a UI pleasant to use.
I think my advice (and I want to write a tutorial someday, like web from first principles, but who has the time) would be to realize the general concept then go to the most specialized thing the platform offers that still fits, and then go ahead and specialize it a bit more with your css/script. When doing a thing, ask: What is it? What does it do? What does it look like? in that order and go from there. But “what is it?” is a kinda deep philosophical question that is easy to beget lol
score 1 · canonical