原生语义化标签比js更可靠轻量且可访问，因voiceover/talkback依赖dom语义结构而非视觉定位；不进tab顺序、无键盘响应，而自带焦点、交互与语义播报。

直接用原生语义化标签和配套属性，比写一堆 JS 更可靠、更轻量、也更可访问。

为什么比

强得多

移动端辅助技术（如 VoiceOver/TalkBack）不是靠视觉找按钮，而是解析 DOM 的语义结构。一个 <div role="button"> 在真机上大概率被跳过，或点击无反馈——它不进 tab 顺序、不响应空格/回车、也没有:active 状态。 <ul> <li> <code><button></button> 自带 keyboard focus、space/enter 触发、disabled 拦截，且屏幕阅读器明确读作“按钮”

图标按钮必须显式设 min-width: 48px; min-height: 48px;，不能只靠 SVG 尺寸撑开

若需自定义样式，用 <label for="toggle"></label> 包裹 <input type="checkbox">，比手写开关控件更稳

DOM 深度超 6 层会让 touchstart 延迟翻倍，实测低端安卓设备延迟达 42ms

contenteditable 的坑：编辑结束怎么捕获？

contenteditable="true" 不触发 input 事件，也不能只监听 blur——用户切屏、弹键盘、点其他区域都可能提前 blur，导致内容丢失。

• 推荐组合：监听 keydown + setTimeout 延迟捕获（比如 300ms 后取 textContent）
• 纯文本场景务必用 contenteditable="plaintext-only"，自动 strip Word 粘贴的冗余格式
• 生产环境必须对输入内容做 XSS 过滤，回显时用 textContent 而非 innerHTML
• 移动端软键盘弹起后，contenteditable 元素易被遮挡，需配合 enterkeyhint="done" 并监听 resize 调整滚动位置

拖放交互在移动端根本不可用，怎么办？

原生 draggable API 在 iOS 和多数安卓 WebView 中完全不触发，连 ondragstart 都不会调用。这不是兼容性问题，是平台级不支持。

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

• 别在移动端依赖 draggable="true"，必须 fallback 到 touchstart/touchmove/touchend
• 为可拖拽项加 tabindex="0"，并用 aria-grabbed 标记状态（如 aria-grabbed="true"）
• 放置区需设 aria-dropeffect="move"，并用 aria-live="polite" 区域播报操作结果
• 视觉反馈不能只靠颜色，要加高对比度边框或阴影，否则色觉障碍用户无法识别拖拽中状态

触摸目标尺寸不是“看着像48×48”，而是 DOM 必须达标

很多开发者用 padding + font-size 拼出小按钮，但 clientWidth × clientHeight 实际不到 48px —— 这会导致 VoiceOver 焦点环跳过、手指误触率飙升。

• 所有 <button></button>、<a></a>、<input> 渲染尺寸必须 ≥ 48×48 CSS 像素，用 Chrome DevTools 实时测
• 相邻可触元素间距至少 8px，否则 iOS VoiceOver 滑动切换焦点时容易连跳两个
• <svg></svg> 图标按钮必须显式设 min-width/min-height，SVG 自身尺寸无效
• 禁用 font-size: 12px + padding: 2px 6px 这类组合，算完很可能不到 48px

最常被忽略的是：语义化标签写了，但没配对使用——比如用了 <nav></nav> 却没确保里面是真实导航链接；用了 <main></main> 却嵌套在 <section></section> 里。这些细节一错，可访问性就断在第一层。