14个网站审计后，我发现了5个让盲人用户崩溃的"低级错误"

三个月，14个生产环境网站，从手搓HTML到Next.js再到堆了十几个插件的WordPress。欧洲无障碍法案（EAA）合规审计做完，我以为会看到各种千奇百怪的边缘案例。结果？同样的5个问题，几乎每个站都踩了一遍。

不是那种需要重写架构的硬核难题。是15分钟就能修好的基础错误——却每天都在折磨真实用户。

13个网站的"图片灾难"：文件名被读给盲人听

这个错误在14个站里出现了13次。但问题不是"没写alt属性"——而是写了比空白更糟的内容。

我见过"image1.png"、"Screenshot 2024-03-15"、纯"photo"。屏幕阅读器会原样朗读这些字符串。想象你在买咖啡机，产品图被读成"斜杠图片斜杠产品斜杠DSC下划线4782点jpeg"——重复六次。

这就是你交付的体验。

修复分两种情况。如果图片传递信息，描述关键内容：

错误示范：alt="photo"

正确做法：alt="蓝色陶瓷部件，高12厘米，哑光表面"

纯装饰性图片（背景花纹、分隔线）则标记为呈现性角色，空alt属性会让辅助技术直接跳过——这不是偷懒，是正确的语义选择。

React代码库有个通病：alt作为prop传进去，但从不要求必填。加一条ESLint规则，jsx-a11y/alt-text能在构建时拦截。别指望代码审查干这种事。

11个站的表单陷阱：placeholder不是标签

这个错误最让我恼火——做对很容易，做错却极其普遍。14个站里有11个存在至少一个表单：输入框有placeholder，但没有label元素。

placeholder不是标签。你开始打字它就消失，这对所有人都是可用性问题；对屏幕阅读器用户更糟：很多辅助技术不会把placeholder可靠地播报为输入框的可访问名称。

视觉上看没问题，但对辅助技术用户是坏的：一个只有placeholder="输入你的邮箱"的输入框。

正确的做法：用label的for属性绑定到input的id，placeholder只放格式示例。

设计实在容不下可见标签？用视觉隐藏标签。.sr-only模式已经存在多年，position: absolute配合特定尺寸和溢出隐藏，对视觉用户不可见，但屏幕阅读器能正常抓取。

我见过太多设计师把"简洁"当成"去掉标签"的借口。你省下的那20像素，换来的是部分用户根本不知道自己该填什么。

键盘导航的"隐形墙"：焦点管理失控

9个站有这个问题。模态框打开后，键盘焦点还在背后页面乱窜；下拉菜单展开，按Tab键直接跳到页面底部；自定义单选按钮组，方向键完全失效。

这像是给轮椅用户修了一道 ramp，却在门口放了根绳子。

React生态里有个偷懒模式：用div套onClick模拟按钮。没有tabIndex和键盘事件处理，鼠标用户一切正常，键盘用户根本触达不到。

正确的做法是：可交互元素用原生语义标签。button、input、select——它们自带键盘支持。必须自定义时，手动实现roving tabindex模式，用aria-activedescendant跟踪当前选项。

测试方法很简单：拔掉鼠标，只用Tab、Shift+Tab、Enter、Space、方向键操作你的页面。如果某功能做不到，你的部分用户也做不到。

颜色对比度：不是"有点淡"，是"看不见"

7个站踩了这条。不是那种明显的设计失误，而是"看起来还行"的灰色文字——#777在白色背景上，对比度3.0:1，低于WCAG AA标准的4.5:1。

对视力正常用户，这是"有点淡"。对低视力或强光环境下的用户，这是直接消失。

有个电商站的"加入购物车"按钮用了浅绿色背景配白色文字，设计团队觉得"清新"。我模拟了绿色盲视角，按钮上的文字几乎融进背景。

别靠肉眼判断。用工具：WebAIM对比度检查器、浏览器DevTools的对比度提示、axe DevTools扩展。把#777改成#595959，对比度从3.0跳到7.0，没有视觉损失，但覆盖人群大幅扩展。

另一个常见坑：链接只靠颜色区分，没有下划线。色盲用户可能完全看不出这是可点击的。加条border-bottom，或者至少保证对比度差达到3:1——这是WCAG对"非文本对比度"的要求。

动态内容的"静默更新"：屏幕阅读器一无所知

6个站有这个毛病。购物车数量变了、表单提交报错、搜索无结果——这些状态变化对视觉用户显而易见，对屏幕阅读器用户完全静默。

就像有人在你背后放了个箱子，却不告诉你。

解决方案是ARIA实时区域（live region）。用aria-live="polite"包裹动态内容，辅助技术会在当前操作完成后播报变化。购物车从0变成1，屏幕阅读器会说"购物车，1件商品"。

但别滥用。把整个页面包在live region里等于制造噪音轰炸。精确标记变化点，用aria-atomic控制播报粒度，aria-relevant过滤不必要的信息。

React用户可以用useAnnouncer钩子统一管理，避免散落在各组件里的live region互相干扰。

为什么这些错误如此顽固？

审计过程中我注意到一个模式：这些问题在代码审查里很难被发现。

alt文本看起来"有内容"、placeholder"能提示用户"、颜色"和设计稿一致"、键盘操作"谁还用键盘啊"——每个错误都有合理的表面借口。

直到你真正用屏幕阅读器走一遍流程，或者用键盘完整操作一次购买流程，才会发现体验断裂在哪里。

有个SaaS团队的CTO跟我说，他们修了alt文本问题后，客服收到的"图片加载不出来"投诉下降了——那些用户其实能看到图片，只是alt文本让他们以为页面坏了。

这五个问题的修复成本都很低。ESLint规则拦截alt问题、设计系统固化标签模式、CI流水线跑axe-core扫描、团队每月一次"无鼠标日"测试。但前提是你把这些检查点嵌入工作流，而不是依赖某个人的善意。

欧洲无障碍法案2025年6月就要对大多数企业生效了。但合规不该是驱动力——那些15分钟就能修好的错误，已经让你的部分用户困惑了多年。

你上次只用键盘操作自己的产品，是什么时候？