Re: Urgent Need for a Standardized Multi-Select Component

I agree with the idea that a better widget for multi-select would be great. But I don't see what the specification is missing.


The fact that lots of people have developed better UX suggests that people have a pretty good idea of how to improve the browser implementation - but whenever there are several different possibilities, the question arises of whether it is better to keep something basic and let library developers offer the range of extra possibilities.


Seems like the issue is more one of implementation in browsers. With very few native browser display systems left, I suspect those who own them are likely to tell us "but it's open source, and you can make a Pull Request". Which is true - for those who have the time and capability to work on browser code as volunteers.


Having worked on browsers, and with the UX implementors, I understand that there is a lot of work that goes into figuring out any UX change - especially one that isn't geared to increasing revenue. 


Rendering speed is often a key concern: anything that slows down how many milliseconds it takes browser (engine) X produces the page ready to interact is not likely to have an easy path to being accepted, even when all the other tests are written and pass. And a lot of that is about demonstrating that the new approach doesn't break (many, nor any "important") existing pages - a demonstration that also takes a lot of effort.

This group might be a good forum for figuring out what it is that people want, getting a broad consensus around how it should behave, and maybe even how to implement it. But ultimately, I think the real work needs to be done in direct browser engineering editing the source code for rendering and interaction engines. It's going on 20 years since W3C stopped doing that, and it was never really in the scope of this particular group.


The various library implementations at least provide some pretty solid starting points...


cheers

On Friday, 22 August 2025 22:37:47 (+02:00), Katie Haritos-Shea wrote:


+1



* katie * 

Katie Haritos-Shea 
Principal ICT Digital Accessibility Architect


Senior Product Manager/Compliance/Accessibility SME 



W3C Advisory Committee Member and Representative for Knowbility 




WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy, IAAP CPACC+WAS = CPWA <http://www.accessibilityassociation.org/cpwacertificants>

Cell: 703-371-5545 <tel:703-371-5545>  | ryladog@gmail.com <mailto:ryladog@gmail.com>  | Seneca, SC | LinkedIn Profile <http://www.linkedin.com/in/katieharitosshea/>


People may forget exactly what it was that you said or did, but they will never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to dictate where we are going.







On Fri, Aug 22, 2025, 12:07 PM Richard Dunne <richarddunnebsc@gmail.com <mailto:richarddunnebsc@gmail.com> > wrote:

Kristjan,


I second your motion.  A dropdown list with checkboxes would be better, something of minimum size that allows single and multiple selection, or something new entirely.  There are probably other elements of the web platform that need redesigning as well, but this I think is a priority.  That was 2c well spent.


Sincerely,


Richard Dunne B.Sc.







On Fri, 22 Aug 2025 at 16:29, Kristjan Kure <kristjan.kure.1@gmail.com <mailto:kristjan.kure.1@gmail.com> > wrote:


Dear HTML Working Group,

It is astonishing that after more than two decades of web evolution, developers still do not have access to a standardized, modern, and accessible multi-select component in HTML.

The existing <select multiple> element is outdated, unintuitive, and inadequate for real-world needs. For years, developers have been forced to rely on third-party libraries such as Tom Select <https://tom-select.js.org/> , Select2, Chosen, and countless others - reimplementing the same functionality over and over. This situation has persisted for far too long, creating unnecessary fragmentation, inconsistent user experiences, and repeated accessibility shortcomings across the web.

The demand for a native solution is undeniable:

Every major design system and framework has built its own version of a searchable, taggable, accessible multi-select.
External libraries collectively serve millions of developers, yet all are workarounds for a missing standard.
Accessibility remains inconsistent, despite decades of awareness, because the burden falls on third-party solutions rather than being addressed at the platform level.

How many years must pass before the web platform offers such a fundamental and widely needed component? The absence of a proper multi-select undermines the very goals of interoperability, inclusivity, and accessibility that the W3C stands for.

I urge the consortium to take immediate steps toward defining and implementing a modern multi-select component as part of the web platform. The community has already proven its necessity through countless parallel efforts. It is time for the standard itself to meet this longstanding demand.

Respectfully, but firmly,

Kristjan Kure

<https://tom-select.js.org/>




-- 
Charles "Chaals" Nevile
Using fastmail.fm because it's worth it