html中“备用验证方式切换”需js控制显隐，推荐用fieldset包裹、region角色标记区块，验证码输入框用inputmode="numeric"而非type="tel"，并做好焦点管理、防抖及无障碍支持。
HTML里怎么实现“备用验证方式切换”按钮组
不能靠纯HTML完成切换逻辑，<select></select>或<radio></radio>只能选值，不自动控制后续表单显隐。必须配合少量JS监听变化并操作display或hidden属性。
常见错误是只写一堆<input type="radio">，没绑定事件，用户点了没反应；或者用<div style="display:none">硬编码隐藏，但没在JS里同步更新<code>aria-hidden和tabindex，导致无障碍访问失败。
- 推荐用
<fieldset></fieldset>包裹整组验证方式，语义清晰，且天然支持disabled批量控制子项 - 每个验证方式区块（短信/邮箱/认证器）用
<div role="region">包裹，并设<code>aria-labelledby指向对应<legend></legend>或<label></label> - 初始状态只让默认项（如短信）可见，其余加
hidden属性——比display:none更利于屏幕阅读器处理 - 手机号输入框才该用
type="tel"，并加pattern="[0-9\s\-\(\)]{7,}"辅助校验 - 验证码输入框统一用
<input type="text" inputmode="numeric" maxlength="6"> - 避免用
type="number"——它会允许小数点和负号，且部分安卓浏览器长按出现增减按钮，干扰体验 - 切换后立即调用
element.focus()，目标元素需有tabindex="0"或原生可聚焦 - 若用
<details></details>，记得在open后对<summary></summary>后的第一个<button></button>聚焦，而非<summary></summary>自身 - 别忘了在切换前保存上一个焦点位置，返回时可恢复——尤其当用户中途取消认证器设置，应回到原radio选项
- 点击后立即将
btn.disabled = true、btn.setAttribute('aria-busy', 'true')、btn.innerHTML = '发送中...' - 用
setTimeout倒计时，结束后恢复按钮，**不要依赖接口响应**——网络延迟可能导致用户以为没发成功，再次点击 - 邮箱发送按钮需额外检查
input[type="email"]值是否通过checkValidity()，否则禁用状态可能被绕过
为什么type="tel"不适合放验证码输入框
虽然短信验证要输手机号，但验证码本身是6位数字，不是电话号码。用<input type="tel">会触发iOS键盘弹出拨号布局，数字键挤在底部，还带*#符号，反而降低输入效率。
更关键的是，type="tel"不触发浏览器的数字校验，而type="text" inputmode="numeric"既能唤起数字键盘，又允许粘贴、不限制长度、兼容性更好（Chrome 66+、Safari 12.1+）。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
认证器（TOTP）配置链接为什么常被忽略focus管理
当用户从短信切到认证器时，页面通常展开一个<details></details>或<div>区块，里面含“扫描二维码”和“手动输入密钥”两个操作入口。如果JS只显示区块，不把焦点移到第一个可交互元素（比如<code><button></button>或<a></a>），键盘用户就得连按多次Tab才能到达，体验断裂。
短信/邮箱发送按钮的防抖和状态反馈怎么做才不翻车
用户狂点“重新发送”是常态，但后端限制60秒发一次。前端不做防抖，会发多条请求，既浪费资源，又可能让后端误判为攻击。
常见错误是只禁用按钮（btn.disabled = true），但没同步更新aria-busy="true"和视觉样式（比如加loading图标），屏幕阅读器用户不知道操作已生效。
最易被忽略的是：所有切换逻辑都得考虑prefers-reduced-motion媒体查询。动画类显隐（比如淡入）应降级为直接show/hide，否则在系统开启减少动画时，区块可能卡在半透明状态不动。
