无障碍设计：从第一行代码起的尊重

　　老张昨天又把前端怼了，说他们新上的那个筛选组件，键盘操作直接卡死——我原以为他又要扯什么交互规范，结果他甩了段屏幕录制的视频，好家伙，焦点跳转逻辑写得跟绕口令似的，盲人测试员按Tab键按到手指抽筋都没走完流程。这事儿让我想起一个月前那场扯皮，当时产品非说无障碍设计是「政治正确」，我叼着冰棍回他：要真政治正确，咱们接口文档里怎么没写「必须支持屏幕阅读器」？

文章配图，仅供参考

　　我原以为这种「形式主义」的需求撑不过两轮迭代，结果你猜怎么着？上周竞品公司因为接口没做键盘导航，被盲人用户集体投诉到消协，直接上了热搜。现在产品经理见我就躲，生怕我又提「无障碍改造要加三个工时」——可他不知道，我们后端早就在偷偷改代码了。比如那个用户信息查询接口，原来返回的JSON里「性别」字段直接用0/1表示，现在改成了「male/female」，前端不用改逻辑，屏幕阅读器就能直接读出「男性/女性」；还有订单状态，从「1/2/3」变成「待支付/已支付/已取消」，测试小妹说连她妈都能听懂。

　　但最绝的是上周五的线上事故。那天下午三点，日志突然刷得太快看不清，我盯着屏幕愣了五秒才反应过来——不是日志量暴增，是某个定时任务把无障碍相关的缓存全清了。原来之前为了省存储，我们把「是否需要高对比度模式」这种用户偏好存进了Redis，结果新来的实习生写脚本时忘了加TTL，导致缓存击穿，所有无障碍适配的接口集体超时。当时监控大盘上红色告警刷得比股票跌停还快，运维小哥抱着机箱嗡嗡响的服务器直冒冷汗，最后还是我翻出半年前的灰度版本，把老接口的限流阈值调高才勉强顶住。

　　事后复盘时，产品经理还在嘴硬：「早说了无障碍是边缘需求，你看现在出问题了吧？」我直接把竞品热搜的截图甩他脸上：「要真边缘，人家干嘛花两百万请咨询公司做适老化改造？」他不说话了，低头戳手机——后来才知道是在查租房信息，工位上贴的「非诚勿扰」便签都卷了边。其实这事儿最讽刺的是，我们为了修复缓存问题，反而把无障碍相关的接口优化得更稳了——比如现在用户偏好数据会同时写进MySQL和Redis，就算缓存挂了，数据库也能秒级响应；再比如所有无障碍适配的接口都加了幂等设计，盲人用户重复点击也不会产生脏数据。

　　现在回头看，那场事故反而是个转折点。之前大家总觉得无障碍设计是「给残疾人用的」，现在才明白，这其实是给所有用户留的「逃生通道」。比如高对比度模式，我这种熬夜写代码的老花眼用着比默认主题舒服多了；再比如键盘导航，上次我外卖筷子掉在地上，单手操作电脑时全靠它救急。更别说那些隐藏功能了——比如我们给屏幕阅读器加的「跳过导航」按钮，本来是为视障用户设计的，结果测试小妹发现，用手机浏览器访问时，这个按钮能直接跳过首页的轮播图，加载速度快了整整一秒。

　　当然，也不是所有改造都顺利。比如那个语音播报接口，前端非要用Web Speech API，结果在Safari上兼容性一塌糊涂，最后还是我翻出三年前的旧代码，把TTS服务改成了后端渲染——现在想想，要不是当时坚持「无障碍要从第一行代码写起」，这功能估计早就被砍了。还有那个表单校验的ARIA标签，产品经理说「普通用户看不到，没必要做」，我直接怼他：「等哪天你眼睛不舒服了，就知道这些标签有多重要了。」他愣了半天，最后默默在需求文档里加了条「所有输入框必须支持ARIA-live」。

　　现在组里已经形成默契了：写接口时，字段命名必须用全称（比如「birthDate」而不是「birth」）；返回数据里，布尔值必须用「true/false」而不是「1/0」；就连日志里的错误码，都要加英文注释——因为屏幕阅读器读数字比读字母慢半拍。这些细节看似多余，但积少成多，反而成了我们的竞争优势。上周竞品公司来挖人，听说我们连测试环境都做了无障碍适配，直接放弃了——他们运维总监说：「你们连咖啡机坏了都要写进事故报告，我们可养不起这种强迫症。」

　　不过话说回来，我们也有不敢动的地方。比如那个祖传的用户表结构，「gender」字段还是CHAR(1)类型，存的是「M/F」——要改成「male/female」，得牵连二十多个接口和三个定时任务。上周我试着提了个工单，结果被运维小哥驳回：「现在改风险太大，等Q4大版本迭代再说。」我盯着工位隔断上贴的「代码要像诗一样优雅」的便签，突然觉得有点讽刺——原来最不优雅的，往往是那些「暂时不改」的祖传逻辑。但转念一想，至少我们已经在为「优雅」努力了，而有些人，连开始都不敢。

（编辑：站长网）

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