Hall of Fame Datalist Athlete Search Audit: Suggestions Are Not Approved Profile IDs
When a school's recognition-program team prototypes a native <datalist> for athlete search — the browser's built-in suggestion control connected to a plain text input — the first audit question is always the same: can a visitor select a name from the popup and have the platform treat that selection as a confirmed, approved athlete record? The answer is no, and the reason is architectural rather than incidental. A datalist is a suggestion list. It offers completions as a visitor types, but it does not restrict the input to those suggestions, does not submit a hidden profile identifier alongside the visible name, and does not guarantee that the value in the input field at submission time matches any record in the recognition database. Same-name athletes — two Marcus Johnsons inducted years apart in different sports, for example — deepen the problem: a name alone cannot uniquely identify a record, and the browser's suggestion popup has no native concept of a stable internal ID. This audit walks recognition-program managers and school IT reviewers through exactly what a native datalist does and does not do, how to structure option values for same-name disambiguation, how to handle the no-result route, and what accessibility limitations the MDN documentation records for programs that must support visitors with assistive technology. What a Native Datalist Does — and What It Does Not Enforce The MDN documentation for the datalist element describes <datalist> as a mechanism that provides suggested values to an associated input. The association is made through two matching attributes: the list attribute on the <input> element must equal the id attribute on the <datalist> element. When the values match, the browser attaches the suggestion popup to the input.
Read More
