无障碍设计：从第一行代码践行技术尊重

　　去年三月份那版迭代，我原以为又是常规的兼容性测试——结果上线前三天，开发小王突然冲进测试区，举着手机喊："这按钮在读屏软件里根本读不出来！" 我当时正盯着用例管理工具转圈，抬头瞥了眼他屏幕，界面上那个"确认"按钮确实安静得像不存在，而旁边广告位的促销文字正被读屏软件用机械音念得欢实。

　　"你早干嘛去了？"我抓过测试机，键盘上有个键按下去不回弹，得用指甲抠着才能弹起来，"上周冒烟测试的时候，读屏软件是不是就卡过？" 小王挠头："我以为是读屏软件自己的问题，毕竟它偶尔抽风..." 我把手机怼到他面前："抽风？这版本迭代了二十次，每次读屏软件都卡在同一个位置，这叫抽风？" 他桌上摆着三台手机，屏幕全亮着，充电线绕得像盘丝洞，最边上那台还插着没撕的塑料膜。

　　后来查代码，发现那个按钮的`aria-label`属性被注释掉了——不是漏写，是有人专门注释掉的。问了一圈，说是为了"优化性能"："反正普通用户看不到，读屏软件解析这个属性要额外耗时。" 我当时就炸了："普通用户看不到，视障用户就活该被优化掉？" 小王小声嘟囔："可产品经理没提过无障碍需求啊..." 我指着白板上的数字——那行被擦了一半的"用户覆盖率98%"："剩下2%不是人？"

文章配图，仅供参考

　　后来灰度上线，果然出事了。有视障用户反馈，登录页面的验证码输入框无法聚焦，读屏软件读不出提示信息。线上监控显示，这个页面的跳出率比平时高了3%。开发紧急修复，发现是前端框架升级时，把无障碍相关的`tabindex`属性默认值改了。小王边改代码边骂："这框架作者是不是没考虑过无障碍？这种基础属性都能动？" 我冷笑："不是没考虑，是觉得没必要考虑——反正大部分团队不测这个。"

　　但最讽刺的是，这次修复反而让性能提升了。测试机跑分时，我发现修复后的页面加载时间比之前快了0.2秒。问开发怎么回事，他说："原来为了绕过无障碍问题，我们加了好多冗余代码，比如用`div`模拟按钮，再手动绑定事件；现在直接用原生`button`，属性都补全了，代码反而干净了。" 我盯着屏幕上的性能曲线，突然想起之前为了"优化性能"注释掉`aria-label`的那段代码——原来真正的优化，从来不是靠删功能，而是靠写对代码。

　　后来我翻了下近三年的漏测记录，发现涉及无障碍的漏测有5次，其中3次导致线上问题。比如去年双十一，有个"限时抢购"按钮没设置`role="button"`，读屏软件读不出它是可点击的，视障用户根本不知道能抢；还有一次，弹窗的`aria-hidden`属性写错了，导致读屏软件把弹窗背后的内容也读了出来，用户听得一头雾水。这些漏测的共同点是：用例没覆盖，开发没意识，测试没重视——大家都默认"视障用户少，出问题概率低"。

　　可市场不会因为用户少就放过你。我查了下行业报告，国内视障用户有1700万，相当于一个二线城市的人口。而且他们更依赖互联网，因为线下出行困难，线上服务是刚需。如果我们的产品连这部分用户都服务不好，还谈什么"用户体验"？就像小王后来跟我说的："以前觉得无障碍是政治正确，现在才明白，这是技术的基本修养——你写代码的时候，连最基础的用户都考虑不到，还谈什么优化、扩展、架构？"

　　现在我们的测试用例里多了个"无障碍专项"，覆盖读屏、语音控制、高对比度模式等场景。开发提代码前，得先过无障碍检查清单；测试机也换了，充电线够长，键盘按键全弹得起来。上周五下班前，小王举着手机冲进测试区："快看！这个按钮在读屏软件里读得可清楚了！" 我接过手机，界面上"确认"按钮被读屏软件用清晰的声音念出来，旁边广告位的促销文字反而被跳过了——因为设置了`aria-hidden="true"`。我笑了笑："这才叫优化性能——不是删功能，是让该工作的功能好好工作。"

　　当然，我们也还有局限。比如有些无障碍问题得用真机测，但测试机型号有限，覆盖不了所有读屏软件版本；再比如，有些开发觉得无障碍是测试的事，代码里还是留坑。但至少现在，大家开始重视了——上周需求评审会，产品经理主动问："这个功能需要支持读屏吗？" 开发组长点头："必须支持，不然测试不通过。" 我坐在角落里，盯着键盘上那个终于能弹起来的键，突然觉得，这可能就是"优胜劣汰"吧——不是市场淘汰你，而是你自己淘汰了自己。

（编辑：站长网）

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