chrome devtools accessibility面板可直接检测关键无障碍问题：mac按cmd+shift+p、win/linux按ctrl+shift+p输入“accessibility”打开，或右键元素选“inspect accessibility properties”；重点查看computed role、name、states三列，分别验证语义角色、可读名称和状态同步。
Chrome DevTools 自带的 Accessibility 面板就能直接检测大部分关键无障碍问题，不需要装插件、不依赖第三方服务——只要打开面板，点一下元素，三列数据就告诉你屏幕阅读器“怎么看”它。
怎么快速打开 Chrome 的 Accessibility Inspector
Mac 按 Cmd+Shift+P，Windows/Linux 按 Ctrl+Shift+P，输入 “Accessibility”，回车选 Show Accessibility；或者右键任意页面元素 → Inspect Accessibility Properties。后者更精准，直接定位到目标节点，避免在树里手动找。
注意：Inspect 按钮（左上角图标）点亮为蓝色后，把鼠标悬停在页面元素上，会实时弹出覆盖层，里面包含对比度、名称、角色、键盘可聚焦性等信息——适合快速扫视整页。
重点看哪三列：Role / Name / States
这三列是屏幕阅读器读取和响应的核心依据，缺一不可：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
Computed Role：应是你预期的角色。比如button、navigation、checkbox；若显示generic，基本说明语义缺失——常见于没配label的input，或用div写的按钮没加role="button" -
Name：必须非空且有意义。来源优先级是aria-label≈aria-labelledby>label[for]>alt> 元素内文本；混用label和aria-label会导致不同读屏器行为不一致（Chrome 优先取aria-label，NVDA 可能忽略） -
States：如disabled、expanded、checked必须实时同步。JS 手动改input.checked = true后，若没触发 DOM 变更或未用aria-checked补充，读屏器仍可能读“未选中”
颜色对比度不足怎么被发现
DevTools 的 Inspect 覆盖层会在悬停时直接标出对比度结果：绿色勾表示 ≥4.5（满足 WCAG AA），橙色感叹号表示不达标。但要注意：
- 它只检查当前元素的
color和background-color计算值，不自动识别伪元素（::before/::after）、SVG<text></text>或currentcolor场景 - 深灰文字（
#333）配浅灰背景（#eee）看似有层次，实测对比度仅 ~2.1，覆盖层会立刻标红 - 禁用态按钮（
:disabled）常被设成#aaaon#f5f5f5，对比度常跌破 3:1，但覆盖层不会主动提醒你“这是禁用态”，得你心里有数去 hover 那一刻
动态内容更新后读屏器不朗读？别只改 DOM
单纯用 textContent 更新错误提示、搜索建议或加载状态，读屏器大概率沉默。它需要明确的“通知信号”：
- 表单提交失败类中断式消息：给容器加
role="alert"（会强制打断当前朗读） - 搜索建议、分页加载等非中断式更新：用
aria-live="polite"包裹容器，并确保新增内容插入位置稳定（不要每次innerHTML = ''再重写） - 禁用
display: none切换显隐：隐藏时加aria-hidden="true"+hidden，显示时移除这两项；否则元素可能彻底从可访问性树中消失
真正卡住人的往往不是 ARIA 属性写不写，而是 DOM 结构本身——比如用 div 实现分页却不加 aria-current="page"，或模态框没设 aria-modal="true"，这些结构性缺失，Accessibility Inspector 一眼就能暴露出来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
