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

　　去年十月那波需求评审会，我原以为只是常规的ETL优化，结果产品经理把屏幕转向我时，我盯着那个"无障碍模式"的开关差点笑出声——不是嘲笑，是那种"终于有人把这事儿当回事"的苦笑。当时桌上排着五台测试机，从华为Mate60到iPhone14，屏幕亮度全调成最低，产品经理说："你们数据仓库组得保证这些设备都能通过屏幕阅读器读出字段含义。"我第一反应是：这他妈不是UI的事吗？

文章配图，仅供参考

　　地铁上掏手机复现问题的时候，我盯着黑暗里泛着蓝光的屏幕，突然想起三年前那个项目。当时客户要求"兼容所有浏览器"，我们为了兼容IE8，把整个数据看板的JS框架降级到jQuery 1.x，结果被前端组骂了半个月。现在回头看，那会儿的兼容性要求跟现在的无障碍设计比，简直是小巫见大巫——IE8至少还能用，屏幕阅读器要是读不出内容，对视障用户来说就是完全不可用。

　　我原以为数据仓库只要保证数据质量就行，结果发现连字段命名都得讲究。那天跟UI组吵架，他们非要把"订单状态"改成"order_status"，说这样符合RESTful规范。我拍桌子说："你们考虑过屏幕阅读器怎么读吗？英文单词之间没空格，读出来就是'orderstatus'，视障用户能听懂才有鬼！"最后妥协成"订单状态_order_status"，虽然丑了点，但至少屏幕阅读器能正确断句。这事儿让我明白，无障碍设计不是加个开关就完事，得从建模第一行代码开始就想着怎么让机器能"读"懂数据。

　　凉了的外卖摆在工位上，我盯着电脑屏幕改ARIA标签。产品经理路过时说了句："就这么点东西，至于改这么久吗？"我头都没抬："您知道中国有1700万视障用户吗？这'点东西'对他们来说可能是唯一能用的数据工具。"他愣了下，没接话。其实我也说不准这个数字准不准，但我知道，如果每个数据仓库工程师都这么想，视障用户能用的工具至少能多几个。

　　最头疼的是日期字段。我们习惯用"20231015"这种格式存日期，节省空间又方便计算。但屏幕阅读器读这种数字会直接念成"二零二三一零一五"，视障用户根本分不清是月还是日。最后不得不改成"2023-10-15"的格式，存储空间多占两个字节，但至少能被正确解读。这事儿让我想起某个小版本里，我们为了优化查询速度，把所有字符串字段都改成了VARCHAR(50)，结果导致部分长文本被截断——现在看来，那点查询速度的提升，跟无障碍设计比起来，简直不值一提。

　　UI走查时，测试组的小姑娘突然说："王工，你们这个'用户画像'页面，屏幕阅读器读起来像在念诗。"我凑过去一听，好家伙，因为字段排列太密集，阅读器把"年龄：30，性别：男，城市：北京"读成了"年龄三十性别男城市北京"，中间连标点都没有。我们连夜调整了HTML结构，给每个字段加了role="presentation"的标签，才让阅读器能正确停顿。那天改完代码已经凌晨两点，我盯着屏幕上密密麻麻的ARIA属性，突然觉得这些看不见的标签，比任何炫酷的数据可视化都更有意义。

　　现在回头看，无障碍设计跟数据质量优化其实是一回事——都是为了让数据能被正确理解和使用。只不过前者服务的是视障用户，后者服务的是业务人员。我敢打包票，未来三年，不懂无障碍设计的数据仓库工程师，就像现在不懂分布式计算的人一样，会被市场淘汰。这不是政治正确，是优胜劣汰的自然法则——当1700万视障用户开始用数据工具时，谁能让他们用得舒服，谁就能活下去。

　　昨天下班前，我把所有核心表的字段都加上了description属性，虽然知道前端不一定用得上，但至少数据字典里有了人类可读的解释。产品经理路过时说了句："哟，王工也开始搞文档了？"我笑了笑没说话——他不懂，这不是文档，是给屏幕阅读器准备的"说明书"。

（编辑：站长网）

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