在构建动态 Web 组件时，遵循 WAI-ARIA 1.2 规范的四条核心规则，旨在平衡视觉设计与无障碍访问需求。这些规则指导开发者如何使用 ARIA 属性来增强 HTML 元素的可访问性，尤其是在原生 HTML 语义不足以支持复杂交互时。本文将根据资料内容，阐述这四条规则的具体要求。
**1. 优先使用原生 HTML 语义**
当可用的原生 HTML 元素或属性已经具备所需的语义和行为时，应优先使用它们，而不是重新利用元素并添加 ARIA 角色、状态或属性。只有在以下情况，使用原生语义可能不可行时，才需要考虑使用 ARIA：
* 该功能在 HTML 中可用，但尚未实现或可访问性支持不完善。
* 视觉设计限制了使用特定原生元素（例如，元素无法按要求样式化）。
* 该功能尚未在 HTML 中提供。
**2. 不改变原生语义**
除非绝对必要，否则不应改变原生语义。例如，如果需要构建一个标题（heading）但视觉上需要它表现为标签（tab），不应直接将 `role=tab` 应用于 `<h2>` 标签。正确的做法是使用一个 `<div>` 元素来承载 `role=tab`，并在其内部放置具有原生语义的 `<h2>` 标签。
**3. 所有交互 ARIA 控件必须支持键盘导航**
如果开发者创建了一个用户可以通过点击、触摸、拖拽、滑动或滚动等方式交互的组件，那么用户必须能够通过键盘导航到达该组件并执行等效操作。所有交互式组件都必须通过脚本实现对标准按键或按键组合的响应。例如，如果使用了 `role=button`，该元素必须能够接收焦点，并且用户必须能够使用 Enter（在 Windows OS 上）或 Return（在 Mac OS 上）以及 Space 键来激活与之关联的操作。
**4. 禁止在焦点元素上使用 `role="presentation"` 或 `aria-hidden="true"`**
在任何可聚焦的元素上使用 `role="presentation"` 或 `aria-hidden="true"` 都会导致部分用户（如使用屏幕阅读器的用户）无法聚焦到该元素，这会造成用户体验中断。如果一个交互元素本身是不可见或不可交互的，那么才可以在其上应用 `aria-hidden`。如果元素是通过 `display:none` 或 `visibility:hidden` 隐藏的，它将不会可聚焦，也会从可访问性树中移除，此时添加 `aria-hidden="true"` 或设置 `tabindex="-1"` 是不必要的。
总结来说，ARIA 的使用应遵循“尽可能使用原生语义”的原则，只有在原生语义无法满足复杂动态组件需求时，才应谨慎地应用 ARIA 属性，并确保所有交互行为都对键盘用户是完全可达和可操作的。