无障碍改造一次次返工，问题出在拆得太急

去年冬天，无障我在社区服务点帮一位视障阿姨办业务。碍改她掏出手机，造次屏幕上是次返拆一个几乎看不见的浅灰按钮，边缘只有一圈极细的工问白线。她点了三次都没点中，题出太急第四次误触跳到别的无障页面，回来时表单已经清空。碍改那张写着取件码的造次小纸条还捏在她手里，她叹了口气说：“我不是次返拆不会用，是工问它不让我用。”

那天回去我把这个页面截图放大到 400%，题出太急才发现问题不是无障“颜色太浅”这么简单：按钮对比度不足，焦点顺序错乱，碍改弹窗关不掉，造次输入框没有可读标签。想一次性全改，开发和设计都摇头。后来我们用了一个笨办法——把“无障碍功能循序渐进怎么拆”当成排期问题而不是情怀问题，按时间顺序一步步来。下面按当时复盘的四个节点讲。

第一周：先只修那个点不中的按钮

失手当天最容易犯的错，是回去列一张几十项的大清单，然后被这张清单吓住，最后一项都没动。我们反过来做：只处理阿姨实际卡住的那一个按钮。

具体动作有三件。第一，把按钮的对比度调到符合 WCAG 2.1 对正文与界面组件的最低要求，工具可以用浏览器开发者工具里的对比度检查，也可以用开源的 contrast checker，读数比肉眼可靠。第二，把点击热区撑到至少 44×44 CSS 像素，视觉上不必变大，用透明的 padding 扩出去即可。第三，给按钮补一个可被读屏读出的名称，不要只靠图标。

这一步的边界要说清：改完不等于“无障碍做完了”，它只是让那一次具体的失败不再发生。验收方法也很朴素——关掉鼠标，只用 Tab 键走一遍，看焦点能不能停在这个按钮上、读屏能不能念出它的用途。如果念出来是“按钮 按钮”，说明名称还没补对，下一步继续查 aria-label 或可见文本。

第二周：把焦点顺序理成一条能走通的路

按钮能点了，新问题冒出来：用键盘 Tab 往前走，焦点会先跳到页脚的“隐私政策”，再弹回中间的输入框，像走迷宫。这就是焦点顺序没跟视觉顺序对齐。

处理顺序上，先看 DOM 结构，再看 CSS。很多人第一反应是加 tabindex 数字强行排序，这在小页面上能糊弄过去，页面一长就会互相打架，后面加个控件就得全表重排。更稳的做法是让 HTML 的书写顺序和视觉顺序一致，少用绝对定位把元素搬来搬去；确实需要跳转的，用跳转链接而不是正数 tabindex。tabindex="0" 用于让本来不可聚焦的元素进入顺序，tabindex="-1" 用于程序化聚焦，这两个值可以放心用，正数要谨慎。

这一步的验收动作是：只用键盘从页面顶部走到提交按钮，中途不迷失、不重复、不跳过。走不通就记下卡在第几个焦点，回到对应的 DOM 节点改结构，而不是继续叠 tabindex。如果团队里没人熟悉读屏软件，至少用 NVDA（Windows）或 VoiceOver（macOS、iOS 自带）实测一遍，比看规范文档更能发现问题。

第三周：弹窗和表单，先保证能关、能读、能纠错

前两步做完，阿姨再试时卡在了弹窗：点“关闭”没反应，按 Esc 也不关。这类问题在无障碍里优先级很高，因为它会把用户困住。

我们的拆法是先修“出口”，再修“入口”。出口包括：关闭按钮可聚焦、Esc 能关、关闭后焦点回到触发它的那个元素。入口包括：弹窗打开时焦点移入弹窗内部，并且读屏能念出弹窗标题。表单部分则先补三样：每个输入框有可见且关联的 label；出错时错误提示与对应字段建立关联，并说明怎么改，而不是只标红；必填项在标签里写明，不要只用一个星号。

这里有个判断点：不要追求一次把所有表单都改完。挑业务量最大、投诉最多的那一两个表单先做，改完让真实用户试。若身边找不到视障用户，可以联系本地残联或公益无障碍团队协助测试，这比内部猜测靠谱。涉及具体合规要求时，以《无障碍环境建设法》及相关部门发布的标准文本为准，拿不准就去官方窗口问，不要照抄网上的二手解读。

第四周：把这次拆法写成下次能照着做的清单

三轮改完，我们把这次的过程整理成一页纸，不是宏大规范，而是四个检查项：对比度读数、热区尺寸、键盘走查路径、弹窗关闭与焦点回归。每次发版前照着过一遍，十分钟能跑完。

这也是“无障碍功能循序渐进怎么拆”的关键：拆的依据是真实用户在哪一步失败，而不是功能清单有多长。每次只解决一个时间节点上的一个动作，验收用键盘和读屏实测，失败就回到对应的 DOM 节点改，不靠叠属性硬撑。改不动的部分，如实记录并在下次排期里留位置，比口头承诺“以后一定做”更负责。

那张取件码小纸条后来再没出现过。阿姨第二次来时，自己点开了页面，按钮一次就中。她没说什么，只是把手机往我这边偏了偏，让我看她已经填好的表单。