按钮交互体验差主因是语义、行为或状态管理未对齐；必须显式声明type属性，禁用态须用原生disabled，加载态需同步禁用与语义更新，并优先使用原生语义化标签确保键盘与屏幕阅读器支持。

按钮交互体验差，八成不是视觉问题，而是语义、行为或状态管理没对齐。直接用 <button></button> 但不设 type，或用 onclick 写逻辑却不处理禁用态，这类细节一错，用户就会卡在“点了没反应”“点了又提交两次”“键盘无法操作”上。

button 的 type 属性必须显式声明

表单内未声明 type 的 <button></button> 默认是 submit，点一下就发请求——哪怕你只想执行 JS。这是线上最常被回滚的 bug 类型之一。

• 表单内所有非提交用途的按钮，一律写 type="button"
• 提交按钮明确写 type="submit"，别依赖默认值
• type="reset" 极少需要，现代项目基本用 JS 控制清空逻辑，避免误触丢失输入
• 如果按钮要提交到不同地址或用不同 method，用 formaction 和 formmethod，而不是额外套 <form></form>

禁用态（disabled）不能只靠 CSS 模拟

用 opacity: 0.5 + pointer-events: none 假禁用，会导致键盘用户仍能 Tab 进去、屏幕阅读器读作“可用”，且焦点无法跳过——这违反 WCAG 2.1。

html-deploy

使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

下载

• 真禁用必须用原生 disabled 属性：<button disabled>提交中</button>
• JS 控制时，用 el.disabled = true，而非 class 切换
• 禁用后，click 事件根本不会触发，不用再加条件判断
• 注意：disabled 对 <a></a> 无效，想禁用链接得换方案（如移除 href 或加 aria-disabled="true" + 阻止默认行为）

加载态按钮要阻断重复点击，且保留语义

“提交中…” 文字 + 自旋图标只是表层，关键是要让按钮在 loading 期间既不可点、又可被辅助技术感知，且操作完成后能恢复原状。

• 进入加载态：设置 disabled + 替换子内容（比如插入 <span>提交中…</span>），不要只改文字
• 退出加载态：恢复原始 innerHTML 或 textContent，并移除 disabled；若用 SVG 图标，确保它也被还原
• 避免用 visibility: hidden 隐藏加载图标——它仍占布局空间，且屏幕阅读器可能跳过
• 更稳妥的做法是用 aria-busy="true" 标记加载中，配合 aria-live="polite" 区域播报状态变化

键盘与屏幕阅读器支持不能靠 tabindex 补救

给 <div> 加 <code>tabindex="0" 再监听 Enter，不如直接用 <button></button>。前者要手动补全 role、aria-label、focus 管理、禁用逻辑，后者开箱即用。

• 所有可点击控件，优先用 <button></button>、<a href></a>、<input type="button"> 这类原生语义化标签
• 非表单区域的交互按钮（如筛选项、折叠面板开关），用 <button type="button"></button>，别用 <div> + <code>onclick
• 如果必须用 <div>（如富文本编辑器内嵌按钮），则必须同时设：<code>role="button"、tabindex="0"、aria-label（不能依赖 title）、onkeydown 监听 Enter 和 Space
• tabindex="-1" 只用于 JS 主动聚焦（如模态框打开后聚焦首元素），它本身不参与 Tab 顺序

按钮交互的复杂点不在动效或样式，而在状态同步：是否可点、是否正在处理、是否被辅助技术正确识别——这三个状态必须由同一套逻辑驱动，否则用户在不同设备上会得到矛盾反馈。