w3c验证器可揪出语义缺失和结构硬伤，如嵌套错误导致屏幕阅读器误读；chrome控制台能扫描aria-*和tabindex陷阱；键盘导航测试暴露焦点丢失；accesskey大多无效应删除。
用 W3C 验证器揪出语义缺失和结构硬伤
老旧 HTML 页面最常暴露的可访问性问题，不是样式错乱，而是根本没告诉辅助技术“这是什么”。W3C Validator（validator.w3.org）能直接报出 Stray end tag、Element div not allowed as child of element ul 这类嵌套错误——这些看似不影响渲染的问题，会让屏幕阅读器跳过整个列表或误读标题层级。
实操建议：
- 粘贴完整源码（含
）到验证器，重点看 <code>Error而非Warning； - 若出现
Attribute role not allowed on element div，说明用了过时的 ARIA 写法，比如在<div role="button"> 上没加 <code>tabindex="0"和键盘事件； - 验证器不报错但页面仍不可读？说明问题在逻辑层面（如缺少
aria-label或焦点顺序混乱），需进入下一步。 - 在控制台执行
document.querySelectorAll("[aria-hidden='true']")，检查是否意外隐藏了关键区域； - 运行
document.querySelectorAll("[tabindex]:not([tabindex='-1']):not([tabindex='0'])")，找出所有手动设了非标准tabindex的元素（如tabindex="1"），它们会打乱自然焦点流； - 对每个疑似交互元素，用
getComputedRole()（Chrome DevTools 的 Accessibility 面板里有）确认其实际角色是否与视觉功能一致。 - 关掉鼠标，纯用
Tab/Shift+Tab/Enter走一遍主流程，记录哪一步突然“失焦”（页面滚动但焦点没跟上、按钮按了没反应）； - 特别注意动态插入的内容（如 AJAX 加载的评论区），它们往往没设置
tabindex="-1"+focus()，导致键盘用户无法到达； - 遇到
display: none切换的区块，检查是否同时移除了aria-hidden——否则屏幕阅读器仍会朗读已隐藏内容。 - 搜索页面所有
accesskey=，90% 应该直接删掉——现代可访问性优先靠语义化结构和键盘流，而非快捷键； - 若必须保留，确保对应元素有明确文本标签（如
<button accesskey="s">保存</button>），且避开s、f、r等系统级快捷键字符； - 测试时用 Windows + Chrome / macOS + Safari 分别按
Alt+S和Ctrl+Option+S，观察是否真触发目标动作，而非弹出浏览器菜单。
用 Chrome 控制台快速扫描 aria-* 和 tabindex 陷阱
老旧页面常把 aria-hidden="true" 错加在导航栏容器上，导致整个菜单对屏幕阅读器不可见；或者给 <div onclick="submit()> 硬加 tabindex="> 却没处理 <code>Enter / Space 键响应——这类问题 W3C 验证器完全无法发现。
实操建议：
用 keyboard-only 模式暴露出口缺失和焦点丢失
鼠标用户看不见的痛点，键盘用户全得靠 Tab 键硬闯。老旧页面里，“跳过导航”链接缺失、表单提交后焦点卡死、模态框关闭后焦点没回退——这些在鼠标操作下毫无感知，却让键盘用户彻底卡住。
实操建议：
别信 accesskey，老页面里它基本等于摆设
accesskey 在老旧页面中高频出现，但几乎全是无效配置：设成 accesskey="s" 却和浏览器 Ctrl+S 保存冲突；或只设在图标按钮上没配 aria-label，导致屏幕阅读器读成“未命名按钮”。
实操建议：
真实痛点往往藏在“能用但不该这么用”的地方：一个用了十年的 <table> 布局页，<code>role="presentation" 可能漏写了；一个 jQuery 插件生成的 tab 组件，aria-selected 状态没同步更新。工具只能扫出表层问题，最终得靠键盘走一遍、听一遍、停顿三秒看焦点在哪——这才是老页面可访问性修复没法绕开的那一步。
