![]()
三个月,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分钟就能修好的错误,已经让你的部分用户困惑了多年。
你上次只用键盘操作自己的产品,是什么时候?
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.