在构建自定义 UI 组件时，确保 ARIA 角色承诺与实现一致的核心原则是：ARIA 角色如同对辅助技术用户的‘契约’。若将普通 div 赋予 role="button"，必须同步通过 JavaScript 完整实现该角色的键盘交互行为（如回车触发点击、Tab 键聚焦等），否则即构成‘坏 ARIA'。
根据 W3C ARIA 作者实践指南（APG）的明确指引，ARIA 角色、状态和属性对辅助技术而言，其功能类比于 CSS 样式——它直接控制非视觉体验的渲染。对于屏幕阅读器用户，错误的 ARIA 使用会歪曲视觉呈现，导致严重的非视觉体验偏差。例如，仅设置 role="button" 却未绑定点击事件或键盘响应，等同于制作了一个下单后自动清空购物车且无法操作的按钮。
ARIA 具有双重属性：既能像披风一样覆盖原始语义（如将链接伪装为菜单项），也能像背带一样增强原有内容（如用 aria-pressed 描述按钮状态）。这种能力赋予开发者极大自由度的同时，也带来了风险。若错误使用 role="log" 或 role="navigation"，可能导致表格被误读为日志、列表被误读为导航区，破坏信息结构。
因此，在实现自定义组件时，务必遵循两个基本准则：一是角色即承诺，必须兑现其交互预期；二是测试先行，应在目标浏览器与辅助技术组合上充分验证兼容性。当前指南未覆盖移动端触控支持细节，部分 ARIA 特性在移动浏览器中尚不支持，开发者需自行评估并补充适配方案。
总之，避免‘坏 ARIA'的关键在于：赋予角色即承担实现责任，不可仅做语义标记而忽略行为承诺。