媒体网站无障碍设计：9个被忽视的技术适配点

　　去年一月份给某媒体网站搭远程办公环境，碰上件特逗的事——他们搞无障碍设计，开发说“按标准来就行”，结果上线后被盲人用户投诉到领导那，说“键盘导航根本用不了，焦点乱飞”。我原以为就是简单的 tabindex 没设对，结果一查，好家伙，九个技术适配点全被当空气了。

　　先说最离谱的：动态加载内容的焦点管理。开发为了省事，用 AJAX 局部刷新页面，但每次加载完新内容，焦点还停在旧位置，盲人用户按 Tab 键直接跳到页面底部，根本找不到新加载的新闻标题。我盯着屏幕上的行数跳了俩小时，发现他们连 JavaScript 的 focus() 方法都没调用，更别说用 ARIA 的 live region 通知屏幕阅读器了。开发还怼我：“用户自己会刷新页面啊。”我直接把投诉邮件甩他脸上：“人家看不见，怎么刷新？”

文章配图，仅供参考

　　第二个坑是表单标签的关联。开发用了 div 模拟 input，说“这样样式好控制”，结果屏幕阅读器根本读不出表单字段的标签。我查了下，他们连 for 属性和 aria-labelledby 都没用，盲人用户输入密码时，只能听到“输入框”，不知道要输什么。开发还狡辩：“我们写了 placeholder 啊。”我差点笑出声：“人家看不见 placeholder，你当是给明眼人看的？”

　　午饭点了外卖，凉了都没顾上吃。第三个问题是颜色对比度。设计说“要高级灰”，结果文字和背景的对比度只有 2.5:1，远低于 WCAG 标准的 4.5:1。我拿色值算了半天，发现他们连 CSS 的 color 和 background-color 都是随手挑的，根本没测过对比度工具。开发还嘴硬：“用户可以调系统字体大小啊。”我直接怼回去：“调大字体能解决颜色问题？你当人家是色盲加近视？”

　　第四个坑是键盘陷阱。页面有个弹窗，按 Esc 键关不掉，只能用鼠标点关闭按钮。盲人用户按 Tab 键进弹窗后，就再也出不来了，只能刷新页面。我查代码，发现他们没给弹窗设 role="dialog"，也没处理键盘事件。开发还抱怨：“键盘导航太麻烦了，明眼人都不用。”我拍了桌子：“无障碍设计是给所有人用的，不是给‘大部分人’用的！”

　　窗外天黑了，运维开了灯。第五个问题是多媒体的无障碍。视频没字幕，音频没文字稿，开发说“用户可以联系我们要啊”。我查了 WCAG 标准，明确要求多媒体内容必须提供替代文本。开发还嘀咕：“又不是所有用户都需要。”我冷笑：“等被起诉的时候，你就知道‘所有用户’包括谁了。”

　　第六个坑是错误提示。表单验证失败时，只显示红色边框，屏幕阅读器根本读不到错误信息。开发说“我们写了 alert 弹窗啊”，结果发现 alert 会被浏览器拦截，盲人用户根本看不到。我让他们改用 aria-live 区域动态播报错误，开发还嫌麻烦：“这得改多少代码？”我直接说：“不改就等着被投诉吧。”

　　第七个问题是跳过导航链接。页面顶部没设“跳到内容”的链接，盲人用户得按二十多次 Tab 键才能到正文。开发说“明眼人不需要”，我反问：“你见过哪个网站没这功能？这是基本无障碍要求！”他们才不情愿地加了个隐藏链接，结果 CSS 写错了，链接根本不可聚焦。

　　第八个坑是 ARIA 属性滥用。开发为了“显专业”，给所有 div 都加了 role="button"，结果屏幕阅读器把所有 div 都读成“按钮”，盲人用户根本分不清哪个能点。我查了代码，发现他们连 ARIA 的基本规则都没搞懂，比如 role="button" 的元素必须支持键盘事件，他们根本没写。

　　最后一个问题是移动端适配。页面在手机上缩放后，按钮太小，手指根本点不准。开发说“用户可以双指放大啊”，我查了 WCAG 标准，明确要求移动端触控目标至少 44x44 像素。他们才把按钮大小调了，结果又把布局搞乱了，我又得重新调 CSS。

　　这九个适配点，说白了就是“优胜劣汰”——不搞无障碍的网站，迟早会被用户淘汰。我原以为开发会抵触，结果他们改完代码后说：“没想到无障碍设计能提升用户体验，明眼人用着也更顺了。”我笑了笑：“这就是标准的力量啊。”不过我也承认，有些细节我自己也没搞透，比如 ARIA 的复杂状态管理，还得再研究研究。下一步打算写个检查清单，让开发自查，省得每次都靠投诉发现问题。

（编辑：我爱制作网_池州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!