ASP无障碍设计：视障开发者高效调试新可能

　　去年暑假被拉去测ASP无障碍调试工具，说是给视障开发者用的，我原以为就是换个读屏软件兼容的事儿，结果第一天就翻车——测试机是台老式戴尔，键盘键帽都快磨秃了，小张蹲在椅子旁边敲键盘，读屏软件突然卡在“当前元素为空”的提示音里，循环了十八秒，他摘下耳机骂了句“这破玩意儿比盲文还难摸”。

　　当时空调坏了，机房里像蒸笼，我盯着屏幕上的代码树，发现个诡异现象：工具的快捷键和系统自带的读屏快捷键冲突了。比如“Ctrl+Alt+S”本来该触发屏幕朗读，结果被工具截胡，直接跳转到“保存调试日志”的弹窗。小张试了三次，每次都是手刚摸到键盘，就被弹窗打断，最后气得把耳机往桌上一摔：“这设计是让视障开发者练盲打吗？”

文章配图，仅供参考

　　我原以为这种“过度解析”是设计缺陷，结果后来发现，视障开发者反而喜欢这种“吹毛求疵”。他们说，普通调试工具只会报错，但这个工具会把所有潜在问题都读出来，哪怕是不影响运行的注释错误，也能提前发现——毕竟他们没法用眼睛扫代码，只能靠读屏软件“听”出问题。就像小张说的：“我们看不见代码，但能听见代码的‘心跳’。”

　　不过最让我意外的是，这工具的快捷键冲突问题，最后居然成了“优胜劣汰”的证明。团队里有个开发坚持要保留所有自定义快捷键，说“视障开发者需要高效操作”；另一个开发则主张禁用所有冲突快捷键，说“稳定比效率重要”。俩人吵了半小时，最后小张插了句：“你们能不能先问问我们怎么用？”原来，视障开发者根本不用快捷键——他们靠肌肉记忆摸键盘，快捷键反而会打乱节奏。最后团队把所有快捷键都改成了“可配置”，默认关闭，结果测试通过率直接涨了三十个百分点（这个数字我敢打包票，因为是我亲手统计的）。

　　说到这儿，我想起上周跟产品老齐吃饭，他吐槽PRD返工四次，开发看完说“这和需求评审不一样”。我跟他讲ASP无障碍工具的事，他喝了口啤酒说：“你们这还算好的，至少有明确的需求——我们老板昨天突然说要加个‘视障友好模式’，PRD写到一半又说‘先这样吧’，结果今天又让把所有按钮放大两倍。”我笑他：“你们这需求一天三变，比我们测试工具的bug还难捉。”

　　其实说到底，ASP无障碍设计能不能站住脚，关键看是不是真的从视障开发者的需求出发。就像那个快捷键冲突的问题，如果团队只听自己的“专业判断”，而不去问实际用户怎么用，最后做出来的东西肯定是个半成品。小张后来跟我说：“我们不需要你们可怜，只需要你们别瞎设计。”这话听着刺耳，但确实在理——无障碍设计不是“施舍”，而是“适配”，适配那些看不见代码、但能听见代码心跳的人。

　　现在这工具已经上线了，听说用的人还不少。我偶尔会去论坛看看反馈，有个视障开发者发帖说：“以前调试ASP页面，得靠同事帮忙看屏幕，现在自己就能搞定，虽然偶尔还是会卡在奇怪的弹窗里，但至少不用求人了。”底下有人回复：“卡弹窗的时候，就当是代码在跟你打招呼吧。”我看了直乐——这大概就是“优胜劣汰”的另一种解释：好的设计，总能在最意想不到的地方，让人会心一笑。

　　不过话说回来，这工具的文档写得是真烂，我昨天试着帮小张查个API，结果翻了半小时才找到，最后发现是文档里的链接失效了。我给他发消息吐槽，他回了个“哈哈”，然后说：“没事，我们视障开发者早就习惯了——文档再烂，总比没有强。”

（编辑：站长网）

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