表单可读性差根源在于基础结构缺陷：label未显式绑定（for与id必须完全一致）、name缺失或语义混乱、type选用错误，导致屏幕阅读器无法识别、用户操作失效、数据提交异常。
表单可读性差，不是样式不够炫，而是基础结构没立住——label没绑对、id和for不一致、name语义缺失，这些地方一错，用户点不到、读不出、输错还不知道哪错了。
label 和 input 怎么才算真正关联上了
屏幕阅读器只认显式绑定，不认“看起来挨着”或 CSS 模拟的位置关系。iOS VoiceOver 和 Android TalkBack 都依赖 for 与 id 的精确匹配来触发焦点和播报。
-
for属性值必须和input的id完全一致（大小写、空格、连字符都不能差） - 避免用嵌套写法
<label>邮箱<input name="email"></label>：DOM 中插入注释、换行或 JS 动态内容时容易断开关联 - 别用
aria-label或title替代label：它们无法点击聚焦，且部分读屏软件不读title - 移动端尤其敏感——没有正确绑定，用户得手动划到输入框才能操作，体验直接降级
name 属性为什么不能省，也不能乱起名
name 是表单数据提交的键名，也是后端接收字段的唯一依据。它不渲染，但决定整个数据流是否可维护、可调试。
- 没有
name的input不会出现在FormData或传统form.submit()的 query string 中 - 禁用模糊命名：
name="input-1"、name="field_x"—— 后端同事看到就懵，日志里也查不到业务含义 - 推荐语义化命名：
name="user_phone"、name="billing_postal_code"，一眼可知用途 - 多选场景注意一致性：checkbox 组统一用
name="interests[]"（PHP 风格）或name="interests"（现代 JS 后端默认聚合），别混用
type 属性选错，软键盘、校验、无障碍全崩
type 不是换图标的小技巧，它直接决定原生行为是否生效。选错 type，等于主动放弃浏览器内置能力。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
-
type="email"：iOS 键盘自动带 @ 和 .com 快捷键；ChromecheckValidity()能拦截空值或无 @ 的输入 -
type="number"值仍是字符串，input.valueAsNumber在 IE 不支持，非法输入时返回NaN；提交前必须手动parseFloat(input.value) || 0 -
type="tel"比type="text"+ 正则更可靠——唤起数字键盘、兼容离线环境、不被用户轻易绕过 - 密码切换场景，严格区分
type="password"和type="text"；禁用 JS 直接改value来模拟明文，否则密码管理器识别失败
高对比度模式下表单还能看清吗
系统开启高对比度时，Windows 和 macOS 会强制覆盖页面颜色，但前提是你的 CSS 主动响应 @media (prefers-contrast: high)，否则所有自定义样式失效，只剩黑底白字或白底黑字的裸奔状态。
- 必须在媒体查询内重置关键样式：
border加粗（至少 3px）、color和background-color显式设为高对比色值 - 焦点样式不能只靠
:focus，要叠加:focus-visible并确保 outline 足够宽、有足够对比度 - 错误提示不能仅靠红色文字——加图标、加
aria-live="polite"、同步设置aria-invalid="true" - 慎用 CSS 变量做颜色控制：变量若未在高对比媒体查询中重定义，会被系统强制覆盖，导致控件“消失”
最常被忽略的是 name 和 type 的组合影响：比如用 type="text" + pattern="[0-9]*" 想限制数字输入，但 iOS 仍弹出全键盘；而换成 type="tel" + inputmode="numeric"，才真正兼顾体验与健壮性。这种细节不测真机、不跑真实辅助技术，根本发现不了。
