原生select是修复下拉菜单可访问性问题的唯一有效方式——它天然支持键盘导航、屏幕阅读器识别、表单提交和移动端系统级选择器调用，而手写div+ul方案存在焦点管理混乱、ar读不出状态、移动端失焦三大硬伤，重构时替换成本远低于修补。
直接用原生 select 替代手写的 div+ul 下拉菜单，是重构期修复可访问性卡死最有效的方式——它不是“折中方案”，而是唯一能同时满足键盘导航、屏幕阅读器识别、表单提交和移动端系统级选择器调用的路径。
为什么手写下拉菜单在重构期会卡死可访问性
老旧项目里常见的 div 套 ul + li 实现的“下拉”，在重构时往往暴露三个硬伤：
- 焦点管理混乱：
tabindex手动维护极易遗漏，Tab 切入后无法用方向键选中，Enter 无响应 - 屏幕阅读器读不出状态：缺少
role="combobox"、aria-expanded动态同步，或aria-selected没随点击更新 - 移动端闪退或失焦：iOS Safari 对非原生控件的 focus 处理极不稳定，尤其在快速切换或弹出后滚动时
这些不是 JS 写得不够细的问题，而是 DOM 语义缺失导致浏览器无法接管基础交互逻辑。重构期强行修补，成本远高于替换。
用原生 select 替换时必须守住的嵌套结构底线
select 能起作用，前提是 HTML 结构严格符合规范。浏览器会自动“修复”错误嵌套，但结果往往是选项消失或生成两个独立下拉框。
- 只允许两种直接子元素：
option和optgroup -
optgroup必须包含至少一个option，且不能嵌套其他optgroup - 禁止在
select内写div、span、ul等非标准子节点 - 分组标题用
optgroup label="硬件"，不要给它加disabled或期望它可点击
错误示例：<select><div><option>A</option></div></select> → 浏览器解析为分离的 <select></select> 和 <div><option>A</option></div>，选项彻底丢失。
保留样式定制需求的最小侵入式改造法
设计师说“必须用新 UI”，又不能放弃可访问性？不用推翻重写，只需两步：
- 把原生
select设为visually-hidden（用 CSS 隐藏但保留可访问性），例如：.visually-hidden { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); white-space: nowrap; border: 0; } - 用
button+ul构建视觉层，通过 JS 同步select.value和select.selectedIndex，并手动触发select.dispatchEvent(new Event('change', { bubbles: true }))
这样既保住了表单提交、键盘导航和屏幕阅读器支持，又让 UI 完全可控。关键点在于：所有用户交互最终都落回原生 select，视觉层只是镜像。
二级联动下拉必须拆成两个独立 select 元素
“主选项选 Saab 后，下方自动展开车型列表”——这不是一个下拉菜单，而是两个逻辑关联、物理独立的控件。强行用 optgroup 模拟二级，或把子选项塞进同一个 select 的 option 里，都会导致：
- 表单提交时
name字段被覆盖（两个控件共用 name 就变成数组） - 键盘导航跳过子项（方向键只遍历一级
option） - 屏幕阅读器无法区分层级关系
正确做法：两个 select，各自有独立 name（如 name="brand" 和 name="model"），用 JS 监听第一个的 change 事件，动态清空并填充第二个的 option 列表。这样后端收到的就是结构化字段，无障碍也自然成立。
重构期最容易被忽略的，是把“视觉一致性”当成技术优先级——可访问性不是附加功能，而是输入控件的基本契约。原生 select 的限制，本质是浏览器对用户操作意图的标准化承诺；绕开它，等于主动放弃这一层保障。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
