Must Know: Accessibility

Prerequisites

• - Accessible naming strategy for labels, headings, and controls.
• - Keyboard-only test scenarios for critical flows.
• - Contrast and motion policy aligned to WCAG AA goals.

Step 1: Keep focus-visible states obvious

Never remove outlines without a visible replacement.

:focus-visible {
  outline: var(--diwa-focus-ring-width, 1px) solid var(--diwa-border-focus, #10a37f);
  outline-offset: var(--diwa-focus-ring-offset, 1px);
}

Step 2: Validate keyboard flow and semantics

Ensure tab order matches visual order and use semantic elements before ARIA workarounds.

<button type="button">Save</button>
<a href="/docs">Read docs</a>

Step 3: Support reduced-motion and clear feedback

Avoid motion-only meaning and provide textual state cues in forms and notifications.

<diwa-inline-notification
  variant="error"
  heading="Save failed"
  description="Check highlighted fields and try again."
></diwa-inline-notification>

Implementation Notes

• - Accessibility checks should run during component work, not only before release.
• - Visible focus is required on intro pages and all component docs pages.
• - Color must not be the only state indicator for errors or success.

Troubleshooting

• - If focus is hard to see, adjust ring contrast and offset tokens without removing visibility.
• - If screen reader output is confusing, verify labels and role semantics first.
• - If keyboard users cannot reach actions, remove click-only custom wrappers.

Next Actions