移动端网页可访问性是涵盖结构、交互、视觉反馈与焦点管理的系统性实践，核心问题在于语义缺失、触摸与键盘路径不一致、动态内容无通知三类；须用原生语义标签、确保焦点同步、启用aria实时通知并覆盖移动端特有场景。
移动端网页的可访问性不是“加个 aria-label 就完事”，而是从结构、交互、视觉反馈到焦点管理的系统性实践。多数问题出在语义缺失、触摸与键盘路径不一致、动态内容无通知这三类上。
用对语义化标签替代 div + class
屏幕阅读器依赖 DOM 结构理解页面，<nav></nav>、<main></main>、<button></button> 这些原生标签自带角色（role）和隐式 ARIA 属性，比 <div role="navigation"> 更可靠。
<ul>
<li>
<code><nav></nav> 必须包裹真正导航链接，不能用于底部工具栏或广告位
<input>、<select></select> 等原生元素，避免用 <div contenteditable> 模拟输入框
<li>
<code><h1></h1>–<h6></h6> 要形成逻辑层级，跳过层级（如 <h2></h2> 后直接 <h4></h4>）会破坏阅读顺序确保触摸操作与键盘焦点完全同步
移动端用户既可能用手指点按，也可能外接蓝牙键盘或开启开关控制（Switch Control）。如果一个按钮能被点击但无法 Tab 到，或者 Tab 到了却没视觉焦点样式，就等于对部分用户关闭了入口。
- 所有可交互元素必须有
tabindex="0"（原生控件默认已有，无需手动加） - 禁用
outline: none—— 改用outline: 2px solid #007aff等高对比样式替代 - 监听
keydown事件时，只响应Enter和Space，不要拦截Tab或方向键 - 触摸目标尺寸至少为
44×44px（iOS 最小推荐），CSS 中用min-height/min-width保证，别只靠 padding
动态内容更新必须触发 ARIA 实时通知
JavaScript 加载新数据、提交表单成功、切换 Tab 页签——这些操作对视觉用户是即时的，但对屏幕阅读器用户是“静默”的，除非你主动告诉它。
- 用
<div aria-live="polite"> 包裹状态区域（如“已保存”提示），文本变化时自动播报 <li>表单提交后，不要只改 DOM 内容，要将焦点移到新内容区或错误摘要处（<code>element.focus()） - 模态框（modal）打开时，必须用
aria-modal="true"并把焦点锁在内部；关闭后焦点应回到触发按钮 - 避免在
aria-live区域里频繁插入/删除节点，会导致播报中断；建议统一用textContent替换
最容易被忽略的是：很多团队只在桌面端做可访问性测试，而移动端的语音指令（如 Siri “点击搜索框”）、开关控制路径、Zoom 浏览器放大后的布局崩坏，几乎从不验证。可访问性不是上线前补个 alt 就算完成的事，它得贯穿开发、测试、发布的每个触点。
