ASP无障碍设计：视障开发者也能高效调试代码

　　去年十一月份那场评审，我原以为又要扯皮两小时，结果老张直接拍桌子说"ASP无障碍调试必须做"——他桌上那摞需求单都快摞到投影仪了，空调还在往下滴水，滴在他那双新皮鞋上，他都没察觉。

　　这事儿能成，说白了就是"优胜劣汰"。咱们之前做的那个埋点工具，排期排了三个月，上线后连测试都没人用——因为测试组觉得"反正有日志，何必多此一举"。可视障开发者调试ASP的时候，连日志都看不清啊！老张当时举了个例子：他盲人朋友写代码，得用屏幕阅读器把代码念出来，念到第三行卡住了，想看看前面变量名，得重新听一遍——这效率，比咱们用IDE慢十倍不止。

　　会议室的白板笔早就没水了，老张用马克笔在玻璃上画流程图，画到一半发现擦不掉，干脆用手指蘸水抹——那画面，像极了咱们之前做的那个"智能擦除"功能，结果上线后用户反馈"擦不干净"。但这次不一样，老张说："咱们不是做慈善，是市场选择。现在大厂都在抢无障碍开发者的市场，咱们不做，别人做，到时候连残障用户都留不住。"

　　我原以为他只是说说而已，结果第二天他就拉了个群，把前端、后端、测试全拽进去，连UI都叫上了——UI小妹当时正在吃外卖，汤洒了一点在需求单上，她一边擦一边说："这功能我做过，之前给某银行做过类似的无障碍适配，结果他们说'视障用户太少，不值得投入'。"老张直接怼回去："那是他们没眼光。你知道现在视障开发者有多少吗？光盲人编程社区就有两万多人，这还不算低视力用户。"

　　开发过程中最搞笑的是测试环节。测试组的老李戴着眼罩调试代码，结果因为屏幕阅读器念得太快，他直接摔了键盘——"这他妈谁能听懂啊！"后来我们才发现，屏幕阅读器的语速设置有问题，默认是"极速"，得调成"慢速"才能用。这事儿后来成了内部梗，每次有人抱怨功能难用，我们就说："至少你不用戴眼罩调试吧？"

　　但真正让我服气的，是老张对细节的执着。比如代码高亮，普通开发者用颜色区分，视障开发者得用不同音效；比如错误提示，普通开发者看红字，视障开发者得听不同的提示音；甚至连缩进都得用空格而不是Tab，因为屏幕阅读器读Tab的时候会卡顿——这些细节，PRD里根本没写，是老张自己找视障开发者聊出来的。

　　上线那天，老张特意叫了几个视障开发者来试用。其中有个小伙子，用屏幕阅读器念完代码后，突然说："这比我之前用的工具快三倍！"老张当场就笑了——他之前一直担心"视障用户太少，ROI不高"，结果那小伙子补了一句："我们虽然少，但粘性高啊。你们要是能把调试工具做好，我们愿意付费。"

　　说到这儿，我想起之前做的另一个功能——"智能代码补全"。排期排了两个月，上线后用户转化率不到5%。为什么呢？因为普通开发者觉得"补全的代码不够智能"，而高级开发者觉得"补全的代码限制了他们的思路"。最后这个功能成了鸡肋，用的人少，维护成本高，最后只能灰度下线。

　　而ASP无障碍调试工具呢？上线第一个月，视障用户的使用时长就超过了普通用户的两倍——因为他们真的需要这个工具。老张后来在复盘会上说："做需求不能只看数据，得看用户是不是真的需要。数据可以造假，但用户的行为不会。"

文章配图，仅供参考

　　现在回头看，这事儿能成，靠的不是什么"用户思维"或"痛点闭环"，就是最简单的"优胜劣汰"。市场会淘汰那些华而不实的功能，也会奖励那些真正解决用户问题的工具。就像老张说的："别总想着做大众市场，有时候小众市场反而更持久。"

　　对了，上周老张又拉了个群，说要做"听障开发者的无障碍调试工具"——这次我主动报名了。因为我知道，这种功能，做了可能没人夸，但不做，一定会被市场淘汰。

（编辑：草根网）

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