Clickable card: div onClick versus anchor tag

WHAT THIS TESTS: This checks whether you default to native semantic elements and understand the concrete accessibility behaviors you lose by faking interactivity on a div.

A GOOD ANSWER COVERS: Because the card navigates to a new page, the correct element is an anchor with an href. A native link is focusable in the tab order, activates with the Enter key, is announced as a link with its destination by screen readers, shows in the status bar on hover, and supports browser features like open in new tab, copy link, and middle-click. A div with an onClick handler is not focusable by default, does not respond to keyboard, is not announced as interactive, and breaks all the browser link affordances. To approximate a link on a div you would need tabindex=0, role=link, an onKeyDown handler for Enter and Space, and programmatic navigation, which duplicates what the browser already gives you for free and is easy to get wrong. The accessible, robust, and simplest choice is the anchor. You can still style it as a card and make the whole card the link target.

COMMON WRONG ANSWERS: Choosing the div because it is easier to style or because the team already uses click handlers, ignoring keyboard and screen reader users entirely. Adding only onClick with no keyboard support. Using role=button for something that navigates, when navigation should be a link, not a button.

LIKELY FOLLOW-UPS: When is a button correct instead of a link. How do you make an entire card clickable while keeping nested links and good semantics. How do focus styles and aria-label fit in.

ONE CONCRETE EXAMPLE: Wrap the card content in an anchor with href to the target page and style that anchor as the card. Keyboard users tab to it and press Enter; screen readers announce a link to the destination; users can open it in a new tab, all with zero extra JavaScript.