媒体网站无障碍设计：9个架构师忽视的关键适配点

　　去年端午加班改架构，运维突然在群里@全员：“WAF日志里这串IP眼熟不？三天扫了十八次/wp-login.php，全是UA带screenreader的。”我盯着屏幕愣了两秒——好家伙，这帮孙子连无障碍适配的接口都不放过，专挑盲人用户常用的读屏工具UA头刷漏洞。

　　当时我们刚给媒体站上了WCAG 2.1，测试环境跑得飞起，结果生产环境被扫出三个高危。最离谱的是/news/detail页的ARIA标签，前端说“为了兼容NVDA读屏器加的”，结果标签嵌套三层，直接给XSS留了后门。我原以为无障碍适配就是改改颜色对比度、调调字体大小，结果被现实狠狠打脸——这哪是适配？分明是给攻击者铺路。

　　第一个坑是键盘导航。测试时用Tab键跑流程，前端拍胸脯说“绝对没问题”，结果上线后收到用户投诉：焦点卡在轮播图里出不来。查日志发现，轮播图的自动播放和键盘事件冲突，盲人用户按Tab键时，焦点被强制锁在图片上，根本跳不到下面的新闻列表。更绝的是，这个“小问题”在测试环境没复现——因为测试机的轮播图被我们手动停了，而生产环境是自动播放的。

　　第二个坑是屏幕阅读器兼容性。我们用了WAI-ARIA的role属性标导航栏，结果NVDA读出来是“导航导航导航”，重复了三遍。前端说“可能是缓存问题”，结果清缓存、换浏览器、换设备，问题依旧。最后发现是role属性嵌套错了——本该标在上的role，被标在了里面的上，屏幕阅读器直接懵了。

　　第三个坑是动态内容更新。媒体站新闻是实时推送的，我们用了aria-live属性标更新区域，结果读屏器要么不读，要么读不全。前端说“按规范写的”，结果一查，发现是推送频率太高——每秒更新一次，读屏器根本来不及读完上一条，下一条就来了。最后被迫把更新频率降到每五秒一次，用户骂“延迟太高”，我们骂“规范坑人”。

文章配图，仅供参考

　　最搞笑的是对比度问题。设计说“按AA级标准调的”，结果测试时发现，深灰色文字在浅灰色背景上，视力正常的人看着都费劲，更别说色盲用户。前端说“数值达标了”，结果一测，实际对比度只有3.8:1，离AA级的4.5:1差了老远。最后发现是CSS里写了!important，把设计稿的样式覆盖了。

　　安全同事后来跟我说：“你们搞无障碍，我们得当半个架构师看。”因为很多适配点直接涉及安全策略——比如CSP、XSS防护、iframe沙箱、键盘事件处理，这些本来是安全组管的事，现在前端为了兼容读屏器，说改就改，根本不通知我们。结果就是，无障碍适配上线一周，安全组收到十二次告警，其中三次是真实攻击。

　　我后来翻了翻WCAG的文档，发现里面根本没提安全——它只管“能不能用”，不管“安不安全”。但现实是，无障碍适配的每个改动，都可能影响安全策略。比如为了兼容读屏器的JavaScript，我们得放宽CSP的script-src；为了支持键盘导航，我们得允许更多的键盘事件；为了动态更新内容，我们得调整XSS防护的阈值。这些改动，每一项都是潜在的安全漏洞。

　　现在回头看，我们当时犯的错，全是“想当然”——以为无障碍适配就是改改样式、调调属性，结果被现实教做人。安全从来不是收入，是成本——你每多做一个适配，就得多考虑一层安全；你每放宽一个限制，就得多防一种攻击。媒体站的无障碍设计，不能只盯着WCAG的条文，得把安全组拉进来一起改——否则，你辛辛苦苦做的适配，最后可能成了攻击者的帮凶。

　　对了，那天运维还发了个截图——WAF日志里，那串扫/wp-login.php的IP，最后溯源到某省残联的IP段。我们当时都懵了：这是真用户，还是攻击者伪装的？到现在也没查清楚。但有一点我敢打包票——如果当时我们没上无障碍适配，这帮孙子绝对找不到这个漏洞。

（编辑：站长网）

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