面向 AI 搜索优化的 SEO、无障碍检查与回答验证
从 AI 搜索查找文档和生成回答的原理出发，说明 SEO 与网页无障碍的作用。以虚构的资费说明页面为例，确认抓取路径和信息准确性，并探讨如何将检查清单与 LLM 审查应用于 CMS 运营。
标签
accessibility
5篇文章
aria-modal="true" 什么都没拦住：模态框焦点逃逸实测与 inert
一个带 role="dialog" 和 aria-modal="true" 的「标准」模态框，按第三次 Tab 时焦点就逃到了遮罩层背后，而 axe 报告的焦点类违规为 0。我把同一份标记分别换成 aria-hidden 和 inert，逐次记录键盘焦点的实际落点。
WCAG 2.2 最小目标尺寸：藏在92分绿灯背后的AA不合格
一排22×22的分页链接，拇指总按偏，Lighthouse却给了无障碍92分。我把WCAG 2.2新增的SC 2.5.8（最小24×24）种进沙箱，用自写脚本和Lighthouse各测一遍。自动工具如今能抓尺寸违规，却把例外判定甩回给你。连24px圆是否相交的间距例外计算，都用实测日志和CSS修复讲清楚。
自动无障碍检测亮了绿灯，仍留下的四道墙
我往一张结账页面里故意埋了八处WCAG障碍，再用axe-core跑一遍。规则型的四处被抓住，需要人来判断的四处却在绿灯背后原样留着。本文用实测日志说清楚自动化在结构上看不到什么，以及补上这块缺口的人工复查清单。
无障碍名称一旦错位，语音控制和AI智能体都按不了这个按钮
给按钮加了aria-label，无障碍树读出来的却是屏幕上根本看不到的字。我在沙盒里复现了WCAG 2.5.3 Label in Name违规，直接从无障碍树读出问题，再用Lighthouse 13.3.0新增的Agentic Browsing评分，看着它从0分变成100分。