ARIA 本身不是“不支持可访问性”，而是——用错、漏用、滥用时，它不仅不提升可访问性，反而会破坏屏幕阅读器的正常理解。关键不在 ARIA 支持与否，而在是否符合 WAI-ARIA Authoring Practices 的语义约束。
为什么加了 aria-label 屏幕阅读器还是读不对
常见现象：给一个 <div> 加了 <code>aria-label="提交"，但焦点无法进入、或读出来后没响应。这是因为 aria-label 只提供名称，不赋予交互能力或语义角色。
- 非交互元素（如
<div>、<code><span></span>）默认不可聚焦、不可操作，加aria-label不等于变成按钮 - 必须配合
role（如role="button"）+ 可聚焦属性（tabindex="0"）+ 键盘事件监听（Enter/Space）才构成完整可访问按钮 - 若已有原生语义元素（如
<button></button>），优先用原生标签——<button aria-label="提交"></button>是冗余的，应直接写<button>提交</button> - 打开时必须用 JavaScript 主动将焦点移到模态框内首个可聚焦元素（如标题、第一个输入框或
focusable的<div tabindex="-1">） <li>需监听 <code>Tab键，在模态框内部循环焦点（Shift+Tab到最后一个，Tab到第一个），阻止跳出 - 关闭模态框后，焦点必须回到触发它的元素（如点击的按钮），否则用户会丢失上下文
- 别只依赖
aria-modal="true"：Safari + VoiceOver 目前仍不支持该属性，必须靠 JS 实现焦点锁定 - 给动态更新容器加上
aria-live="polite"（非中断式）或aria-live="assertive"（高优先级，慎用） - 确保内容是插入/替换 DOM 节点，而非仅改
textContent；某些旧版 NVDA 对纯文本变更不敏感 - 避免在
aria-live区域内放交互控件（如按钮），否则语音会连读“保存成功 按钮”，造成歧义 - 如果消息需要手动关闭（如 toast），记得用
aria-label或aria-describedby明确说明关闭方式，比如<button aria-label="关闭保存成功提示">×</button>
role="dialog" 打开后焦点没锁住怎么办
模态框（modal）若未正确管理焦点，屏幕阅读器用户可能意外跳转到背景内容，甚至无法关闭。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
动态内容更新后，屏幕阅读器没朗读怎么办
例如表单提交后显示 <div id="msg">保存成功</div>，但用户听不到提示——这是典型的实时区域（live region）缺失。
最常被忽略的一点：ARIA 不是补丁，它是对原生语义的补充或覆盖。当你发现自己要反复加 role 和一堆 aria- 属性时，先问一句——这个组件能不能用 <button></button>、<details></details>、<nav></nav>、<table> 等原生元素重写？能的话，90% 的 ARIA 问题就不存在了。</table>
