Consider the following markup:<!-- example 1 --><section><h2>Hi there</h2>...</section><!-- example 2 --><div><h2>Bye there</h2>...</div>
As far as what gets programmatically exposed to assistive technologies (AT), there is no discernible difference between the
<div>that contain their respective
<h2>elements. Semantically, the
<section>specifies an explicit "section" in the document outline, but this is not actually exposed in reality. Rather, the meaningful elements here are the headings which implicitly indicate a new section (or sub-section depending on the heading's rank).
[...] Regarding the
<section>element's implicit ARIA role, it is best named – thus exposing its role – only when absolutely necessary. Overpopulating a web page with landmarks will reduce their ability to help users find the most important parts of web pages. In other words, if everything's a landmark then there's nothing really special about them, is there? Instead, rely on proper heading levels to indicate implicit sections and sub-sections of your content. People using a screen reader, for example, can navigate by these headings (commonly the H key), and even their specific levels (1 to 6 keys), to quickly navigate to these different areas of your page.
On July 6 2021 the ARIA in HTML specification, that I co-edit along with Steve Faulkner and Patrick H. Lauke, became a W3C Candidate Recommendation Snapshot. As the W3C promoted in their invitation for implementation of ARIA in HTML:
[The ARIA in HTML] specification's primary objective is to define requirements for use with conformance checking tools used by authors (i.e., web developers). These requirements will aid authors in their development of web content, including custom interfaces/widgets, that makes use of ARIA to complement or extend the features of the host language [HTML].
Access Guide is a friendly introduction to digital accessibility - specifically to help understand WCAG 2.1 (Web Content Accessibility Guidelines), the official resource for legal compliance.