This document contains my personal summary of how ARIA and HTML interact. It might be useful background reading.
ARIA lets you set three things on an element: roles, states, or properties. States and properties are only conceptually different so we can discuss them together as stoperties for conciseness. (ARIA uses the term "attributes" but there are already several uses of that word floating around so we don't continue that practice in this document.) An element's role is a string and an element's stoperties are given by a string-to-string map.
Like many features of elements, elements maintain their "true" role and stoperties as internal state. There are also HTML attributes which can affect these. For example, <hr> will have role separator, even though it has no role="" attribute.
HTML's ARIA section has lots of information for authors, but only some of it applies to user agents. Notably, the strong native semantics and restrictions are irrelevant for UAs. What matters are the default implicit ARIA semantics, which give default values for the ARIA roles and stoperties when they haven't been overwritten by attributes.
Examples:
<meter>elements by default have no role.<hr>elements by default have theseparatorrole.<noscript>elements by default have thearia-hiddenstate set to "true".<input>elements that are checkboxes will by default have theiraria-checkedstate set to "mixed", "true", or "false" depending on the checkedness and presence/absence of theindeterminateattribute.
In all these cases, using HTML attributes like role="", aria-hidden="", or aria-checked="" will override the role or stoperty value exposed to accessibility technologies.