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

　　去年一月份那会儿，我原以为无障碍设计就是个“政治正确”的噱头——毕竟咱搞元数据管理的，代码里塞个aria-label都嫌多余。结果周四下午四点二十，测试组的老王拎着键盘冲进机房，屏幕上的监控告警红得跟血似的：“你们这API文档的导航栏，屏幕阅读器根本读不出层级！”当时我盯着三百多条未处理的告警短信，心想这老王又来挑刺，结果他直接掏出手机播放了一段录音——导航栏的“按钮”被念成了“未命名的链接”，连续点了十八次才触发下拉菜单。

　　这事儿闹到CTO那儿，他甩了句“优胜劣汰，技术尊重不是口号”。我原以为要大改架构，结果发现最坑的居然是前端那套自研的组件库——某个“高复用”的Tab组件，为了省代码把role属性写死了，导致屏幕阅读器把所有标签都识别成“可点击区域”。更绝的是，这组件在工单系统里被引用了三百七十二次，改一个就得全量回归测试。那天晚上我在值班室啃冷掉的咖啡，看着白板上的“无障碍适配优先级”被划了又改，突然觉得这活儿比元数据血缘分析还烧脑。

　　后来跟测试组对需求时，老王说了句大实话：“你们写代码的总觉得无障碍是额外功能，可对视障用户来说，这就是基础功能。”我当场反驳：“那为什么不用现成的组件库？”他冷笑：“你们自己写的库，连键盘导航都不支持，还怪用户？”这话扎得我半天没接茬——毕竟我们确实为了“性能优化”砍掉了键盘事件监听，觉得“反正现在都用鼠标”。结果现在要补，得在每个交互组件里加keydown事件，还得处理各种浏览器兼容性问题，工作量直接翻倍。

　　最搞笑的是，有次我在内网论坛吐槽“无障碍设计太麻烦”，被一个视障开发者回怼：“你们觉得麻烦，是因为从来没把我们的需求当回事。”他贴了段代码对比：我们写的按钮是“提交”，他写的按钮是“提交”。我盯着那行代码看了五分钟，突然意识到——我们所谓的“简洁代码”，在别人眼里可能是“无法使用的代码”。

　　现在回头看，这事儿能推进下去，全靠CTO那句“优胜劣汰”。他直接把无障碍适配纳入KPI，要求所有新功能必须通过WCAG 2.1 AA级测试，否则不给上线。刚开始前端组怨声载道，说“这又不是核心功能”，结果被市场部甩了份数据——某竞品因为无障碍做得好，被残联推荐，季度流量涨了二十个百分点。现在他们改代码比谁都积极，上周还找我讨论怎么用元数据管理无障碍测试用例，说要“把适配规则沉淀成资产”。

　　不过说实话，有些适配真的离谱。比如有个弹窗组件，为了满足“所有交互元素必须可键盘访问”的要求，前端给每个按钮加了tabindex="0"，结果视障用户用Tab键切换时，光标在按钮之间疯狂跳转，根本没法操作。最后还是测试组的老王出了个主意：把非重点按钮的tabindex改成"-1"，只保留主要操作按钮可聚焦。这事儿让我明白，无障碍设计不是“堆功能”，而是“精准满足需求”——就像我们搞元数据管理，不是数据越多越好，而是要保证血缘关系准、影响分析快。

　　现在机房的噪音还是那么大，告警短信还是那么多，但白板上的“无障碍适配进度”已经从“0%”划到了“85%”。上周五下班前，老王又来找我，这次是笑着递了杯热咖啡：“那个导航栏的无障碍改造，屏幕阅读器终于能正确读出层级了。”我喝了口咖啡，突然想起去年一月份那个下午——如果当时我们继续嘴硬，说“视障用户占比低，不用适配”，现在可能已经被市场淘汰了。优胜劣汰，有时候就是这么残酷。

文章配图，仅供参考

（编辑：汽车网）

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