In HTML accessibility work, ARIA roles should be applied when:

• A. They are always required for all elements.
• B. Native semantics are insufficient to convey functionality to assistive technologies.
• C. They replace native HTML elements completely.
• D. They are only needed for visual design.

Answer: (B)

ARIA roles are used to communicate a control’s purpose to assistive technologies when the native HTML semantics don’t fully describe how a component should behave. Native HTML elements come with built-in meanings that screen readers and other ATs understand, so you should rely on those first. If you create a custom widget or interaction with non-semantic elements (like divs or spans) and the default semantics don’t clearly convey what it does, adding ARIA roles helps ATs understand the function—for example, giving a custom control a role of button or dialog and providing any necessary state information.

This is not something you apply to every element, and it’s not a replacement for native HTML elements. ARIA should complement, not replace, real HTML semantics. Also, ARIA doesn’t implement behavior or keyboard control by itself—you still need proper focus management and keyboard interaction. The other options miss the purpose of ARIA: it’s not about applying it to all elements, not about replacing native elements, and not about styling.