表单控件 tabindex 出错因 DOM 顺序与视觉顺序不一致，应语义化结构+CSS flex/grid 控制视觉流；search 类型触发表单专用键盘与补全；required 失效多因未调用 reportValidity()；触控目标须 ≥48×48px。
表单控件的 tabindex 顺序为什么总出错
浏览器默认按 HTML 顺序分配 tabindex，但人眼阅读顺序常和 DOM 结构不一致——比如左侧标签、右侧输入框的布局，实际 Tab 键却先跳到标签再跳输入框，用户得按两次才能进编辑态。
解决方法不是全设 tabindex="0"，而是用语义化结构配合 CSS 视觉流分离：
- 所有
<label></label>必须绑定for属性或包裹<input>，否则屏幕阅读器无法关联 - 避免用
float或绝对定位打乱 DOM 顺序；改用display: grid或flex并通过order控制视觉位置，不破坏逻辑流 - 禁用
tabindex="-1"除非明确需要程序聚焦（如模态框首次打开时聚焦第一个可操作元素）
input type="text" 和 type="search" 的行为差异被低估了
type="search" 不只是加个 × 清空按钮——它在 iOS Safari 中会触发搜索键盘（带“搜索”回车键），在 macOS 上支持 Spotlight 式自动补全，且部分浏览器会默认禁用拼写检查。而 type="text" 一律弹出普通键盘，回车键行为不可靠。
选型关键看场景：
立即学习“前端免费学习笔记（深入）”；
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 搜索框：无条件用
type="search"，并加results="5"声明建议条数，让浏览器知道该缓存历史 - 地址/姓名等通用字段：用
type="text"，但必须配spellcheck="false"（地址常含大小写缩写，拼写检查反而干扰） - 密码类字段：永远不用
type="search"，清空按钮会暴露掩码长度，且搜索语义与安全场景冲突
required 属性失效时，八成是没处理 validity API
用户点了提交按钮却没提示错误？不是 required 失效，而是你没监听 invalid 事件或调用 reportValidity()。原生校验只在表单 submit 或 input 失焦时触发，且错误样式依赖 :valid/:invalid 伪类——但很多 CSS 重置掉了这些状态。
实操要点：
- 提交前手动调用
form.reportValidity()，它会触发校验、滚动到首个错误项、返回布尔值 - 别只依赖
:invalid改边框色；iOS Safari 对该伪类支持不稳定，需搭配 JS 添加data-invalid属性做兜底 -
required对<select></select>生效的前提是首选项的value=""且selected，否则用户选了空值也过不了校验
移动端触控区域小于 48×48px 就是反人类设计
哪怕一个 checkbox 看起来够大，如果它的 width/height 是 16px，周围又没留足够空白，手指就容易点偏。WCAG 要求最小触控目标 44×44px，iOS Human Interface Guidelines 明确推荐 48×48px。
真正有效的做法：
- 对
<input type="checkbox">或radio，不要放大 input 本身，而是扩大其<label></label>的点击区域：用padding或min-width/min-height控制 label 尺寸 - 禁用
touch-action: none在表单区域，否则会屏蔽系统级长按复制、双指缩放等辅助操作 - 避免用
zoom: 0.75缩小整个表单来“适配小屏”，这会让触控目标物理尺寸变小，违背人机工程本质
人机工程学不是加一堆 ARIA 标签，而是让手指、眼睛、键盘、屏幕阅读器都能走同一条路径——路径错了，再多修饰都白搭。
