必须使用原生实现滑块，因其自带完整ARIA语义、键盘交互（←→↑↓/Page Up/Down）和无障碍支持；禁用自定义div+JS方案，避免焦点、朗读、范围值同步等无障碍失效问题。
滑块元素必须用
，别手写 div 模拟
手动用
+ JS 实现的“滑块”几乎必然失败：键盘无法聚焦、方向键无效、屏幕阅读器读不出当前值和范围。原生
←
/
→
调整 1 步，
↑
/
↓
同样生效，
Page Up/Page Down
调整 10 倍 step），这是无障碍底线。
常见错误现象：
role="slider"
加在非原生控件上，但没实现
aria-valuenow
动态同步、没处理
keydown
事件、没设
aria-valuemin
/
aria-valuemax
—— 屏幕阅读器会直接跳过或报“未知控件”。
必须设置
min
、
max
、
step
和
value
属性（哪怕初始值是 0）
禁用
tabindex
：原生
input
默认可聚焦，加
tabindex="0"
可能导致重复焦点
不要包裹在
for
关联 —— 直接用
input
放进
aria-label
或
placeholder
或旁边文字说明（非
aria-label="调节对比度"
，但需确保该描述足够具体（“调节滑块”这种无效）
避免同时写
aria-label
：会导致重复朗读
动态更新
aria-valuetext
要谨慎，多数情况不需要
aria-valuetext
用于提供比数值更自然的描述（例如 “中等亮度” 而非 “50”），但它会覆盖屏幕阅读器对
aria-valuenow
的默认朗读。滥用反而降低可理解性。
性能影响：每次拖动都触发 DOM 更新 + 屏幕阅读器重读，可能卡顿；兼容性风险：旧版 NVDA 对频繁变更的
aria-valuetext
支持不稳定。
仅当数值本身无意义时才用：比如色温滑块 2000K–6500K，可设
aria-valuetext="暖光"
/
"冷光"
必须配合
aria-valuenow
使用，不能单独存在
更新时用
element.setAttribute('aria-valuetext', text)
，别用
innerHTML
或其他间接方式
移动端 Safari 和旧版 Android WebView 有 focus 焦点穿透问题
部分 iOS 版本下，
focus
事件，导致依赖
:focus
的样式（如外框高亮）失效，也影响某些 JS 逻辑（如自动朗读当前值）。
根本原因：WebKit 将触摸视为“指针操作”，不模拟键盘焦点流。这不是 bug，是平台行为差异。
用
ontouchstart
+
element.focus()
强制补焦（注意防重复）
视觉反馈别只靠
:focus
：叠加
:active
或 JS 添加临时 class
测试真机：Chrome DevTools 的设备模拟器无法复现此问题
复杂点在于「语义完整性」和「平台行为差异」的平衡——写对属性只是起点，得在 Safari、TalkBack、NVDA、VoiceOver 上逐个验证焦点路径、朗读内容、键盘流是否一致。最容易被忽略的是：没测试盲人用户真实操作路径，只盯着代码是否“符合规范”。