The author shares a personal experience with web accessibility that highlights a common pitfall when using ARIA (Accessible Rich Internet Applications) roles. After shipping a component with correct ARIA roles and passing automated audits, the author discovered that screen reader users struggled to interact with it. The issue arose because the component's markup was semantically sound, but the addition of an ARIA role introduced confusion. The author had set a button element as a link with `role="link"`, which led to inconsistent behavior with keyboard navigation and screen reader announcements. To fix the problem, the author removed the ARIA role and relied solely on the semantic HTML of the button element. This decision restored predictable behavior, affirming that native HTML elements already provide significant accessibility features. The author emphasizes that semantic HTML should be the primary choice, using ARIA only when necessary to communicate additional states or to handle complex interactions. The article also outlines a workflow for ensuring accessibility: start with native HTML, test with keyboard navigation and screen readers, and only add ARIA to clarify missing states. The author warns against using ARIA to redefine roles, as it can create unexpected outcomes. By understanding when and how to use ARIA appropriately, developers can enhance accessibility without compromising the functionality that browsers already support.