返回知识库

产品与设计 · 交互状态与指针

禁用态Disabled

用正确语义阻止暂时不可用的控件,并说明原因、条件和恢复后的下一步。

补齐条件,看提交按钮自己说出恢复路径

这是注册表单的提交按钮。输入邮箱、勾选条款,按钮会从「挡住 + 原因」变成可提交;点击后它再变成「提交中」防重复,最后变「已提交」。

禁用尽职:按钮身上写明缺什么,补齐后自动恢复可操作。

键盘 Tab 试试:原生 disabled 让按钮不进焦点序列;补齐条件后它才重新出现在 Tab 路径里。

禁用要尽职的四个要点

刚才面板里发生的,就是这四点。

  • 原因写在控件上:按钮身上直接写「还缺有效邮箱」「还需同意条款」,不是只靠灰色。
  • 恢复路径可见:补齐条件后,按钮自身由灰挡变为主色「可以提交」,无需刷新或猜测。
  • 提交中禁用防重复:点击后按钮变「提交中…」并禁用,和「条件未齐」的禁用语义不同。
  • 原生 disabled 退出 Tab:键盘跳过禁用按钮,避免焦点陷阱;自定义组件用 aria-disabled 时要补焦点策略。

什么时候该用 disabled

从用户信号判断,别把 disabled 当万能灰。

  • 用:控件暂时不可用,但补齐条件或等待结束后会恢复——表单未齐、提交中、限额未达。
  • 改用只读 / 隐藏:信息永久不可达,灰掉只会让人误以为「等一下就好」。
  • 权限不足:说明原因并给只读入口或申请路径,不要和普通灰禁用混为一谈。

怎么用得对

从开始到判断的最短路径,关键是真阻断 + 给原因。

  • 表单内用原生 <button disabled>:默认不可激活、退出 Tab、读屏识别为本页演示的样子。
  • 原因用 aria-describedby 关联控件,并在视觉上写在控件附近(本例直接写在按钮身上)。
  • 自定义组件(div / 自定义按钮)用 aria-disabled="true",并仍要阻止动作、文档化焦点去向。
  • 不要用 opacity / cursor: not-allowed / pointer-events 模拟禁用却不阻断——读屏和键盘仍能触发。

正反例:同一个提交按钮

只改一个关键选择:禁用时是否把原因写出来。

正例 · 尽职禁用

提交按钮 disabled 时身上写「还缺有效邮箱」;补齐后恢复可点。用户知道缺什么、怎么办。

反例 · 伪禁用

提交按钮只设 opacity:.4 + cursor:not-allowed,仍可 Tab 触发且无原因。用户卡住,可能反复点击。

快速自测

后台「删除」按钮对你灰掉,最该先补什么?

继续查证

术语的技术定义和行为以这些一手或权威资料为准。

下一步学

和本知识点经常一起出现的概念。