搜索框必须用<form>包裹、type="search"声明、显式<label for>绑定，才能实现键盘跳转、屏幕阅读器识别和可预测提交；禁用accesskey和aria-label替代方案。
搜索框必须能被键盘用户一键跳转、被屏幕阅读器准确识别用途、提交行为可预测——这三件事没做到，就不是真正可访问的搜索框。
用 accesskey 实现快速跳转？别用
虽然 accesskey="s" 看似能帮键盘用户“秒达”搜索框，但它在现实中几乎不可靠：
- Chrome、Firefox、Safari 对组合键定义不一致（Alt+S / Ctrl+Alt+S / Cmd+Option+S）
- 极易与浏览器原生快捷键冲突（比如 Alt+S 在 Edge 会打开“分享”面板）
- 用户根本不知道快捷键存在，也无处发现，属于“隐藏功能”
真正有效的替代方案是加一个 <a href="#mainSearchInput">跳到搜索框</a> 的跳过链接，并确保它在 tabindex="-1" 之外第一个获得焦点。这个链接对所有键盘用户可见且可预测，比 accesskey 稳定十倍。
label 必须显式绑定，不能靠视觉对齐
很多页面“看起来有 label”，但点击文字无法聚焦输入框，或 VoiceOver 完全读不出字段含义——问题就出在 label 和 input 没建立浏览器可识别的关联。
立即学习“前端免费学习笔记（深入）”；
- 正确写法：
<label for="site-search">站内搜索</label><input type="search" id="site-search" name="q"> - 禁用隐式包裹：
<label>站内搜索<input type="search" name="q"></label>在 iOS Safari 和旧版 TalkBack 中关联易断裂 - 禁用
aria-label替代：aria-label不触发点击聚焦，也不被所有辅助技术当作“可操作控件标签”解析
type="search" 不只是换了个名字
type="search" 是语义锚点，影响软键盘、清除按钮、无障碍角色识别和浏览器自动填充逻辑：
- iOS 键盘会显示“搜索”回车键（配合
enterkeyhint="search"更稳） - Chrome/Safari 自动添加右端清除按钮（无需 JS 模拟），且该按钮自带可访问名称
- 屏幕阅读器朗读时会明确说“搜索输入框”，而非“文本输入框”
- 若用
type="text"+ JS 校验，上述能力全部丢失；type="search"才是基础保障
提交行为必须可预期，不能依赖 JS 隐式触发
可访问性最常被忽略的一环：用户必须清楚“按下回车会发生什么”。这要求表单结构本身就能表达意图。
- 必须用
<form method="get">包裹input[type="search"]和提交按钮 -
name属性必须存在且有意义（如name="q"），否则 FormData 为空，后端收不到参数 - 避免纯 JS 提交（如监听
input事件发 AJAX）而不提供传统表单 fallback——这会让部分辅助技术用户完全无法提交 - 如果要用即时搜索（AJAX），必须同时保留原生表单提交路径，并用
aria-live="polite"向屏幕阅读器播报建议列表变化
真正的难点不在加 ARIA，而在于让原生 HTML 结构本身就能承载语义和行为——label 绑定、form 包裹、type="search" 使用，这三者缺一不可，且顺序不能错。任何试图用 JS 补丁绕过结构缺陷的做法，最终都会在某个屏幕阅读器版本或某台旧手机上失效。
