视障友好：服务网格工程师的无障碍建站运维避坑指南

　　我原以为无障碍是前端的事，结果上周三灰度完那个弹窗埋点，盲人用户压根没触达——连屏幕阅读器都根本没扫到它。投影仪对焦不准，你盯着那片模糊的蓝色边框看了三分钟，小张还在那儿讲「语义化标签覆盖率」，我手机震了七次，但谁敢掏出来看啊。

　　跟老板争执那次，就在1月刚开完年会后。他说“视障用户占比太小，ROI撑不起排期”，我直接把PRD里那行「支持VoiceOver/SpeechViewer兼容性测试」划掉，当着他的面。他愣了一下，说“你划得倒快”。我点头，其实心里发虚——我划掉的是需求，不是问题。白板笔没水了，写“无障碍=法律红线”那几个字，最后一笔拖成灰褐色尾巴，像条快断气的蚯蚓。

　　我们真做过一个功能：点击按钮后自动生成ARIA-live区域播报操作结果。做了两周，上线后没人用。不是没人反馈，是根本没人触发。因为按钮本身没focusable，键盘tab过去直接跳过——而盲人用户根本不知道那里有个按钮。我查日志发现0.3%的页面交互漏斗里，这个节点卡死在step-0。小李说“反正埋点也挂上了”，我说挂上等于没挂，他耸肩去改另一个弹窗的z-index，桌上那摞打印的需求单没人收，风吹过来掀了两页，一张飘到空调下面，滴下来的水正好打湿了“无障碍验收标准”那一行。

文章配图，仅供参考

　　外卖的汤洒了一点在桌上，顺着木纹往下滑，快流到键盘缝里，我拿纸巾按了两下，没吸干。这时候王工突然说：“要不要把accessibility tree也加进可观测大盘？”我差点笑出声。可观测？我们连自己写的组件有没有render aria-hidden=false都靠手动audit。他认真记笔记的样子，让我想起去年review那个“暗色模式兼容性”的需求，最后只加了个CSS class——可屏幕阅读器根本不读class名啊，它只读role、name、state。我原以为只要加了role="button"就行，结果测试环境里被JAWS读成“按钮，未命名”，用户根本不知道这玩意儿干啥用。后来才知道，必须配合aria-label或内部文本节点。这事我没跟任何人提过，因为提了也没人改。优先级排在“首页动效优化”后面。

　　会议室的椅子少一把。小张坐在我旁边折叠椅上，腿翘着，手机一直震，他没接，但亮屏看了三次。我看不清他屏幕内容，但锁屏时间戳是16:27、16:31、16:38。最后一次他点开又关掉，叹气说“客户又要加个浮层引导”。我嗯了一声，其实脑子里在想另一件事：我们那个灰度集群的Envoy配置里，有一段header rewrite规则把所有User-Agent含“Accessibility”字段的请求给拦截了——因为当初防爬虫策略写死了，误伤。运维老陈说“早修了”，但我今天下午刚查了canary pod的日志，last 24h还有17条匹配该规则的403，IP段全指向已知辅助技术代理池。我没截图，也没报issue，怕他们说“你早不说”。

　　所以现在我不跟人聊“为什么要做”，我就问三个问题：tab顺序能跑通吗？屏幕阅读器念出来的话，和你想让用户知道的一样吗？当所有CSS失效时，这页面还能不能完成核心任务？问完这三个，90%的所谓“无障碍优化”当场崩盘。剩下10%，要花三倍时间补context。比如那个被砍掉的语音反馈功能，其实背后要动服务网格的sidecar拦截逻辑——得让gRPC响应头带个自定义accessibility-payload，再透传给前端做tts合成。但PRD里没写这一段，开发当然不会主动扛。我原以为提个RFC就行，结果会议纪要里只写了“待评估技术可行性”。

　　自己那份没人看的文档。存网盘里叫《Mesh侧无障碍可观测checklist_v2.1_draft》，建于去年11月，更新时间停在12月17日。里面有一条写着：“检测服务返回的HTTP header是否包含accessibility-aware标志，否则视为降级路径”。这条我至今没落地，因为得改控制平面配置生成器，而控制面今年Q1目标是“支持WASM插件热加载”——无障碍？不在OKR里。无所谓。真的无所谓。你做好了，没人夸；你漏了，用户不骂你，但下次迭代永远轮不到你这个模块。

　　下周我打算抽半天，把所有mesh-gateway路由规则里的rewrite动作全grep一遍，看看有没有硬编码过滤UA的行为。不拉会，不走流程，就下班前默默跑个脚本。要是真有，我直接提个patch，附言写“防误伤辅助技术用户”。至于会不会合进去……谁知道呢。我手边这杯咖啡凉透了，杯底一圈深色印子，像没擦干净的log error。

（编辑：草根网）

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