Isn’t HTML basically this? It has accordions and date pickers (<details> and <input type="date">) and basically everythimg most folks needed react or the like for 6 years sgo, it’s stylable, it’s accessible. I feel like the issue here isn’t the lack of such a system, it’s people who don’t follow web standards (they add cool new stuff all the time), don’t search MDN before implementing controls or adding dependencies, and don’t reform old habits when new stuff comes out.
Part of the author’s point, as evidenced by the articles he links to, is that it’s easier to get accessibility wrong on the web than it is to get it right. The lawsuits keep pouring in. Usability and themability are also important to the producers and consumers of components that are the author’s primary audience. <details> is far from ideal; <input type="date"> is far from ideal; <input type="number"> is a disaster; etc. The author is specifically calling for an alternative to waiting for new standards to provide all the accessible, usable, themable components we need as off-the-shelf elements.
The trouble with vanilla html is that back in the very earliest days of the web there was a competing goal to that of making components stylable; the goal was to make components feel native to the system where they are beng displayed. Roughly half of components in html are ‘native like’ and half are styleable. The native like components can’t be used if you want to make a web app that looks nice and consistent across devices.
The idea of semantic and accessible components makes sense for small projects with tight budgets. For interfaces made by major companies however, it is strange to think that some designer will loose sleep over pixel alignment, but somehow the user experience for visually impaired users with sceen readers will just magically happen via semanticism. Ideally, the bling UX would be intentionally designed as a separate product. Anyone who’s used a screen reader knows that simply having a tree of components in arbitrary order, while technically accessible, is extremely time consuming to navigate.
The screen reader UI is an entirely unique UI, unrelated to the one used by sighted people. If we are serious about design and have the resources we should try to give blind people something better than the equivalent of what you see when you reflow a pdf with tables.
This is global so not for a particular brand, but it’s themeable so it can evoke your brand, but in real life a brand is more than just a set of colors and a voice… I dunno, I think this already effectively exists as Material Design. That is a Google-branded system, but it seems to have convinced the design world it’s not branded at all. At least this one is focused to only the web platform.
Headless UI is going in the same direction the author is asking. It implements a lot of common design patterns and enforces (relatively) good accessibility while imposing minimum opinion on styling and DOM structure. It could still use an accessible accordion and a styleable date picker, but architecturally, it’s on the right track.
However, many of these libraries are tied to a specific technology, namely React, which limits their reach.
A lot of this functionality is a lot more straightforward with declarative DOM bindings. So long as that does not exist in standards, a framework has to fill that need. FWIW, Headless also supports Vue, which is an excellent framework.
Edit: seriously though, we might need something like this in a hundred years. We invented all this crap like yesterday morning, historically speaking. The idea we’ve got it sorted well enough that everybody should stop experimenting because we’ve got the right answers to all the interaction requirements of even today, let alone tomorrow, is a very tough sell.
Isn’t HTML basically this? It has accordions and date pickers (
<details>and<input type="date">) and basically everythimg most folks needed react or the like for 6 years sgo, it’s stylable, it’s accessible. I feel like the issue here isn’t the lack of such a system, it’s people who don’t follow web standards (they add cool new stuff all the time), don’t search MDN before implementing controls or adding dependencies, and don’t reform old habits when new stuff comes out.Part of the author’s point, as evidenced by the articles he links to, is that it’s easier to get accessibility wrong on the web than it is to get it right. The lawsuits keep pouring in. Usability and themability are also important to the producers and consumers of components that are the author’s primary audience.
<details>is far from ideal;<input type="date">is far from ideal;<input type="number">is a disaster; etc. The author is specifically calling for an alternative to waiting for new standards to provide all the accessible, usable, themable components we need as off-the-shelf elements.The trouble with vanilla html is that back in the very earliest days of the web there was a competing goal to that of making components stylable; the goal was to make components feel native to the system where they are beng displayed. Roughly half of components in html are ‘native like’ and half are styleable. The native like components can’t be used if you want to make a web app that looks nice and consistent across devices.
This sounds a lot like Ark UI:
The idea of semantic and accessible components makes sense for small projects with tight budgets. For interfaces made by major companies however, it is strange to think that some designer will loose sleep over pixel alignment, but somehow the user experience for visually impaired users with sceen readers will just magically happen via semanticism. Ideally, the bling UX would be intentionally designed as a separate product. Anyone who’s used a screen reader knows that simply having a tree of components in arbitrary order, while technically accessible, is extremely time consuming to navigate.
The screen reader UI is an entirely unique UI, unrelated to the one used by sighted people. If we are serious about design and have the resources we should try to give blind people something better than the equivalent of what you see when you reflow a pdf with tables.
This is global so not for a particular brand, but it’s themeable so it can evoke your brand, but in real life a brand is more than just a set of colors and a voice… I dunno, I think this already effectively exists as Material Design. That is a Google-branded system, but it seems to have convinced the design world it’s not branded at all. At least this one is focused to only the web platform.
Headless UI is going in the same direction the author is asking. It implements a lot of common design patterns and enforces (relatively) good accessibility while imposing minimum opinion on styling and DOM structure. It could still use an accessible accordion and a styleable date picker, but architecturally, it’s on the right track.
Oops. He already mentioned Headless.
A lot of this functionality is a lot more straightforward with declarative DOM bindings. So long as that does not exist in standards, a framework has to fill that need. FWIW, Headless also supports Vue, which is an excellent framework.
Situation: there are 12 competing standards….
Edit: seriously though, we might need something like this in a hundred years. We invented all this crap like yesterday morning, historically speaking. The idea we’ve got it sorted well enough that everybody should stop experimenting because we’ve got the right answers to all the interaction requirements of even today, let alone tomorrow, is a very tough sell.