The semantics are indeed different in screen readers and the elements will be announced differently and behave differently in the accessibility tree (by virtue of having ARIA roles like e.g. "term"[0] or "definition"[1]). Note that ARIA roles change drastically how elements are announced -- a screen reader would take forever to announce elements if they were not scoped by their role because it would have to announce what an item is not (e.g. if it's unchecked, which is announced for "checkbox" roles, which can be and often are <span>s). ARIA roles make a bunch of ARIA attributes hidden (or, conversely, shown) in the accessibility tree.

It also gives context to additional ARIA attributes like aria-details[2] because now the screen reader knows that the details are the definition or whatever, and will announce those appropriately.

Using semantic elements allows you to have the proper ARIA roles (and thus the accessibility tree be properly scoped) without thinking too much or polluting your DOM tree with aria-* attributes.

There are also some other semantic-related benefits. E.g. from <dfn>'s MDN page[1] "if you include an id attribute on the <dfn> element, you can then link to it using <a> elements. Such links should be uses of the term, with the intent being that the reader can quickly navigate to the term's definition if they're not already aware of it, by clicking on the term's link."

I know you can already id-link to a simple <span>, but the thing is the screen reader would be able to announce that the link is to a definition so the user is already aware of the link purpose even before clicking it (unsure if any do this, but they could). Or maybe the user agent could build up a list of definitions automatically and allow you to quickly look up them, even if they are not explicitly linked.

Most importantly: you might think that sighted users cannot tell the difference between the default styling of all those elements, but they often can by virtue of what they are visually surrounded with and other contextual clues that are not available while using a screen reader. E.g. `<cite>` is often surrounded by other visual cues that might not be obvious to screen reader users which have a very local and narrow contextual scope (you can only hear elements one at a time, while visual users can see a bunch of context at a glance).

Also, sighted navigation is much faster than navigating via keyboard+narration so the additional affordances really help non-sighted users. Imagine having to wait for a whole paragraph to be narrated to get to some textual clue near the end of the paragraph, or even further down the content... or worse, above the current content (think an <h2>Definitions</h2> for example) which will normally not get visited while you navigate piecewise. It's very hard (impossible?) to read/navigate diagonally with a screen reader. We get so much instant info visually that we take for granted and it's just not there for screen reader users.

Lastly, you can style those differently in CSS even if the default user agent stylesheet does not. E.g., by giving <dfns> a dashed underline or a different mouse cursor. I know you can do that by manually annotating <span>s with classes but the thing is... you don't need to. So you can give additional visual affordances to sighted, but also to cognitively-impaired or partially-blind users too.

[0] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

[1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

[2] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

[3] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/df...