Using ARIA attributes instead of semantic elements is bad for accessibility.
Sure, if there is a HTML element that works then use it, but not every UX pattern is expressible in HTML without specifying roles/attributes (e.g. tabs [1]) and not all browsers support recent HTML elements/attributes (such as using details/summary for accordions).
ARIA patterns [2] has a list of examples for UX components and their examples specify/use ARIA roles/attributes.
Are you still coding to support Internet Explorer? All browsers have supported details/summary since an Edge switched to Chromium in 2020.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
https://www.scottohara.me/blog/2022/09/12/details-summary.ht...
While it’s good to use well-implemented semantic elements when possible, there are still plenty of places where either the built-in browser behavior isn’t actually very accessible (like native form validation), or where you just can’t avoid it (using aria-disabled instead of disabled for submit buttons, setting aria-pressed for toggle switches, setting aria-expanded for buttons that trigger modals, situations where you need aria-hidden/sr-only, etc).
Though once popovers and the invoker command api hit baseline widely available, we’ll be able to drop some of that.