快速发现可访问性硬伤需聚焦三类基础问题：图片缺alt、表单控件无label、键盘焦点不可见或跳转错乱；推荐chrome lighthouse和axe devtools零配置检测，但须人工核对关键交互流与语义标签有效性。
怎么快速发现可访问性硬伤
很多可访问性问题在开发阶段就能暴露，根本不用等上线后被用户投诉。最典型的三类问题：图片缺 alt、表单控件没 label、键盘焦点不可见或跳转错乱。这些不是“体验优化”，而是基础功能缺失——屏幕阅读器会直接跳过无 alt 的图片，视障用户根本不知道那里有内容；没 label 的 <input> 在 VoiceOver 下无法被正确识别。
推荐两个零配置入口：
- Chrome 自带的
Lighthouse→ 选 “Accessibility” 项跑一次，5 秒出报告，重点看红色项（如 “Image elements do not havealtattributes”） - 安装
axe DevTools插件 → 打开 DevTools 切到 axe 标签页，点 “Analyze”，它会高亮所有违反 WCAG A 级规则的节点，且每条都带修复指引
注意：别只信 Lighthouse 的自动检测。它对 role 误用、aria-hidden 和视觉隐藏内容冲突这类逻辑问题不敏感，必须人工核对关键交互流（比如模态框打开时是否禁用背景焦点、关闭后焦点是否回退到触发按钮）。
如何避免语义标签变成“装饰性 div”
写了个 <header></header>，但 IE11 或旧版 Android WebView 里它被当成了未知 inline 元素，样式全崩——这不是 CSS 写错了，是浏览器压根没把它当块级元素解析。
验证方法很简单：
- 打开 Elements 面板，手动展开 DOM，确认
<nav></nav>、<main></main>这些标签是否完整存在，而不是被自动包裹进<div> 或直接丢弃<li>在 Console 执行：<code>document.querySelectorAll('header, main, nav, footer').length，返回值为 0 就说明语义标签未被识别 - 检查
是否独占第一行，前面**不能有 BOM、空格、注释**；DevTools Elements 顶部渲染模式必须显示 <code>Standards，不是Quirks - 不要在静态 HTML 里硬编码
aria-*再靠 JS 覆盖，容易遗漏；统一由 JS 控制，比如el.setAttribute('aria-expanded', 'true') - 动态内容更新后，如果依赖
aria-live，确保目标元素已挂载且未被display: none或visibility: hidden隐藏（这两者都会使区域失效） - 测试时别只听语音，用 Chrome 的 “Accessibility” 标签页查看可访问性树结构，确认
role、name、value是否与预期一致 - 本地开发时，关掉鼠标，全程用
Tab/Shift+Tab/Enter/Space操作一遍核心流程（登录、筛选、提交） - 用 Chrome 的 “Keyboard Navigation” 实验性功能（
chrome://flags/#enable-experimental-web-platform-features）开启焦点高亮，直观看到焦点是否跳过重要控件 - 真机测试不必覆盖全部机型，优先测 iOS Safari + Android Chrome，这两个占移动端可访问性问题的 80% 以上；尤其注意虚拟键盘弹出后是否遮挡输入框、是否触发
resize事件重排布局
兼容方案不是“全量 polyfill”，而是按需补丁：header, nav, section, article, aside, footer { display: block; } + 条件加载 html5shiv（仅 IE9 及以下）。现代项目里，只要不支持 ES6 的环境基本也都不支持语义标签，所以优先保证 JS 加载前的 HTML 结构可用。
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
怎么让 aria 属性真正起作用
aria-label 写了，但屏幕阅读器还是读错；aria-live 区域更新了，却没播报——常见原因是属性值动态变更后未触发可访问性树刷新，或者父容器用了 aria-hidden="true" 却忘了排除子节点。
实操要点：
特别注意：Safari 对 aria-modal="true" 支持不稳定，iOS 16.4+ 才真正生效；替代方案是用 inert 属性（需运行时检测：const el = document.createElement('div'); el.inert = true; return el.inert === true;），比纯 CSS 遮罩更可靠。
为什么自动化测试总漏掉关键路径
CI 流水线里跑通了 axe-core 的单元检查，但真实用户反馈“搜索框无法用键盘操作”——问题出在自动化只扫描 DOM 快照，不模拟用户行为流。可访问性缺陷往往藏在交互链路里：比如点击按钮后弹出的菜单是否可 tab 进入、是否支持方向键导航、ESC 是否能关闭。
轻量化落地建议：
复杂点在于：可访问性不是“加几个属性就完事”，而是整个交互模型要适配线性导航逻辑。最容易被忽略的是状态同步——比如一个切换开关，视觉上变了，但 aria-checked 没同步更新，辅助技术就永远不知道当前状态。
