Native HTML or a custom ARIA widget: which interaction should you build?

Native HTML controls carry browser behavior, semantics, keyboard support, form integration, and accessibility mappings that custom elements must recreate. Styling constraints can be frustrating, but replacing a standard control transfers a large compatibility contract to the product team.

Start with the semantic question

If an action navigates, use a link. If it performs an action, use a button. If the browser provides the required input or disclosure behavior, test whether the native element can meet the product need before designing a custom widget. ARIA can communicate semantics and state; it does not implement keyboard behavior or repair an inappropriate element automatically.

Require a case for custom behavior

Document the user need unavailable from native controls, supported browsers and assistive technologies, keyboard model, focus behavior, touch and pointer behavior, high-contrast and zoom behavior, validation and error states, and maintenance owner. The ARIA Authoring Practices warns that no ARIA is better than bad ARIA and that example support can vary across browser and assistive-technology combinations.

Implement the complete interaction

• Use the expected role, name, value, state, and relationship.
• Support documented keyboard commands without overriding browser or assistive-technology conventions.
• Keep focus visible, ordered, and intentionally restored after temporary interfaces.
• Provide single-pointer alternatives to path gestures and appropriately sized targets.
• Test loading, empty, disabled, invalid, and error states, not only the ideal state.

Test with real combinations

Automated checks can identify missing names or invalid attributes but cannot prove the interaction is understandable and operable. Test representative browsers, keyboard use, zoom, forced colors, touch, and relevant screen-reader combinations. Prefer deleting custom behavior when the same result can be achieved more robustly with the platform.

Kiwi can help design and implement accessible components within a scoped product engagement. Formal conformance claims and specialist assistive-technology evaluation require an appropriately defined review.