原生HTML表单校验不降低可访问性——用错才出问题；正确使用能提升体验，因浏览器自动同步aria-invalid、关联aria-describedby并支持reportValidity()语义化播报。
原生 HTML 表单校验机制本身不会降低可访问性门槛——用错了才会；正确使用反而能显著提升屏幕阅读器用户的体验，因为浏览器原生校验自动同步 aria-invalid、触发 aria-describedby 关联、支持 reportValidity() 的语义化错误播报。
为什么加了 required 但屏幕阅读器还是读不出错误？
根本原因不是校验没生效，而是错误信息没被正确关联到输入框。浏览器只在调用 reportValidity() 或触发表单 submit 事件时，才把原生错误文案挂载到 aria-describedby 并激活 aria-invalid="true"。
- 仅靠
checkValidity()返回false不会更新任何 ARIA 状态，屏幕阅读器完全无感知 - 如果表单加了
novalidate，原生校验被禁用，reportValidity()也失效，必须手动设置aria-invalid和aria-describedby - 错误提示元素（如
<span class="error"></span>）必须有id，且该id要和输入框的aria-describedby值严格一致
setCustomValidity() 后怎么让屏幕阅读器读出中文提示？
关键不在“怎么读”，而在“什么时候读”——只有当 reportValidity() 被调用，且输入框处于焦点或刚失去焦点时，屏幕阅读器才会播报关联的错误文案。
- 写
input.setCustomValidity("请输入手机号")只是注册文案，不触发播报 - 必须紧接着调用
input.reportValidity()（或其父form.reportValidity()），才能激活 ARIA 状态并触发读屏 - 旧版 Safari（reportValidity() + 自定义文案支持不全，错误可能静默，需降级 fallback：手动聚焦 +
aria-live="assertive"区域播报 - 避免用
title属性替代错误文案——它不可靠，多数读屏软件忽略或延迟播报
怎样让错误提示真正“可操作”而不是只读一遍就消失？
屏幕阅读器用户需要能回溯、重听、定位错误字段。单纯依赖浏览器气泡提示远远不够，必须提供持久化的错误容器，并保持焦点可及。
立即学习“前端免费学习笔记（深入）”；
- 错误文案不能只放在 tooltip 或临时
div里；应渲染在 DOM 中固定位置，比如输入框下方或表单顶部摘要区 - 表单顶部错误摘要需带
role="alert"或aria-live="assertive"，确保首次播报后仍可手动导航返回 - 提交失败后，应将焦点
input.focus()到第一个无效字段，并确保该字段有aria-invalid="true"和有效aria-describedby - 别用
display: none隐藏错误提示——要配合aria-hidden="true"和hidden属性，否则读屏可能仍尝试读取
最易被忽略的一点：所有原生校验行为都依赖于 label 与 input 的 ID 严格绑定。哪怕 for="email" 和 id="Email" 仅差一个大写 E，屏幕阅读器就无法把错误提示和控件语义关联起来——它根本不知道你在说哪个字段错了。
