MOD.10 控件DOC-10-011AUTHOR · 姜未白2025-08-06READ · 4 MIN

搜索框的清除按钮时机

超数频控件可访问性受控模式

控件是交互的原子件，也是最轻易被轻视的复杂度来源。一个按钮有多少种状态？团队的答案是八种，少一种就是一类 bug。本文以可访问性为纲整理控件工程学。

SEC.01受控与边界

复盘中还藏着一条：组合控件的解耦信条：一个控件只做一件事，复杂表单靠组合而非继承。搜索框不带下拉逻辑，下拉不带过滤逻辑，可访问性的每个零件都可单独测试和替换。

有一条经验值得单独记录：所有规则都要有复查节点：一线团队给可访问性的规范设了季度复审，到期清点例外和豁免，过期的清理，失效的修订。规范不呼吸，就会变成化石。

// CASE FILE · 实测档案

实测：日期选择器补键盘操作后，盲人测试员首次独立完成预约流程，用时 4 分钟。

禁用态需要补工具提示说明原因，否则就是一堵无解释的墙。「该按钮在审核中不可用，预计 2 小时后解锁」比一个灰按钮友好太多，实现成本只有一个 tooltip。

这里再补一笔：文档写得再好也挡不住人员流动，所以一线团队把可访问性的规则尽量固化进工具：lint 规则、CI 卡点、脚手架模板。规则长在工具里，团队才不会失忆。

开关控件的瞬态保护指中间态：请求未返回前开关锁定在过渡样式，不允许二次点击把状态翻转成未知。项目组在这个受控模式上栽过跟头，修复后开关类缺陷归零。

复盘中还藏着一条：复盘文化比做法本身更重要：每次受控模式的线上问题都要求 48 小时内出复盘，聚焦流程漏洞而非个人责任。三年下来，同类问题的复发率降到个位数。

此外还有一条底线：视觉回归测试用像素快照：每个控件八态截图，PR 里自动比对。发布后可访问性的样式类回归缺陷拦截率 27%，设计师终于不用肉眼验收每一版了。

复盘中还藏着一条：边界处理是控件质量的分水岭：滑块到端点、步进器到极值、日期到月末，这些可访问性的角落场景本组全部写成表驱动测试，一条用例一个断言，新增控件照抄这个骨架。

复盘中还藏着一条：下拉超过 200 项务必上虚拟滚动，渲染节点压在 30 个以内。线上数据中千项列表的打开耗时从 800ms 降到受控模式的 60ms，滚动帧率稳定 58fps，改动只在内部实现。

顺带记录一个细节：每个控件要有一页「何时不该用我」：日期范围用两个选择器还是面板、可访问性的选型边界写清楚，误用率下降后，定制需求也少了一半。

顺带记录一个细节：树形控件的懒加载按展开触发：默认只拉根层，展开时拉子层并缓存。可访问性的首屏请求数从 47 个降到 3 个，深层节点仍可按需直达——两全的做法来自一次深夜重构。

此外还有一条底线：控件库的发布节奏固定为双周：需求攒着一起发，变更日志按破坏性分级标注。受控模式的下游团队据此安排升级，再没人被突袭式发版打断。