This is the working model of HTML I teach when needed. Browser devtools are used to demonstrate.
HTML stands for hypertext markup language. You can ignore hypertext as an old buzzword for now. The big deal about HTML is that it (and URLs) are the original web. It's fair to call the networking layer the internet and the concept linking of HTML files at URLs together the web. The web is in some ways the "open source" user interface layer of the internet. HTML was designed specifically for this, which leads to a few things.
First, as something designed for sending information about UI over internet networks, it is a serialization. If you don't already know what that means, it means a transformation of data into a format suitable for sending over networks. HTML is literally a plain text serialization of a UI to be rendered in a specific state. If that's confusing, take a button. In HTML you write a button tag with a disabled attribute:
<button disabled />When a web browser loads that HTML, it will parse it into a DOM and render a disabled button.
(* I note that I'll talk more about this when teaching app distribution builds later.)
Like any language, HTML has syntax, grammar, and vocabulary. A markup language takes words and puts something around them to annotate the words somehow. To mark up the word Label as a button using a tag:
<button>Label</button>Learn the details of the HTML syntax later if you want to, but you will be using (whatever specific HTML-like), which has its own syntax instead.
One last noteworthy thing on this topic is that a markup language like HTML is already 100% purely declarative. Declarative web UI is not an innovation, it's built in.
In summary, HTML is a declarative language sent over the internet to web browsers that serializes the content, copy, controls, and even state of a UI.
Second, HTML being designed to mark up UIs means that of course its vocabulary of tags are meaningful annotations needed for the copy, content, controls, and state of the UI. That's why a button tag exists!
There are many other elements used in UIs. For all of those elements to work like the button tag, the web browsers all need to support the same tags. That's really all HTML semantics are: the tags that are supported, which UI parts they refer to, and what interactions they have.
People got together at an organization called the W3C and agreed on a list of UI elements in a process called standardization. Alignment was not always as good as it is today. That is something you must not ever take for granted. As hard as it is today, it was much harder in the past.
Now is where accessibility comes in. Buttons existed before the web. Your operating system has buttons. A browser runs on your OS. Each OS is different. Each OS has a unique UI and has accessibility tools built in, like VoiceOver on OSX.
(Most companies provide MacBooks, so I can usually assume it.)
Spare some time for VoiceOver later, because you're responsible for apps working in screen readers.
(* I note we'll talk more about testing apps later.)
Web or native, the tools have to understand the same UI elements the same way. Web or native, VoiceOver will not read the text on a meme out to you. It is an image. It isn't text.
That's why HTML has the alt attribute. Now everyone can enjoy it.
An unstyled button in a web browser often looks like the button in your OS UI. That's partly historical—so users of the OS will recognize it. But let it remind you that, layers down, your app UI integrates all the way to the OS with HTML semantics.
Third party accessibility tools like JAWS rely on shared HTML semantics. Browser plugins like LastPass rely on shared HTML semantics. Search engines rely on shared HTML semantics.
If someone ever tells you this doesn't matter, they are wrong.
In summary, HTML's widely shared and consistently understood semantics formalize common UI patterns. Accessibility involves a lot of different technologies that only work together because they have a common understanding of UI patterns and semantics that are documented in HTML.
(I then use a codepen of mine to demonstrate.)
https://codepen.io/morewry/pen/poOxLmL
What's the difference between these? Why do you use one or another? You already know certain things about button and link semantics as a user of the web, whether you realize it or not.
Interaction events can happen on all of them. But a div can't get focus without extra effort. If it does get focus, it doesn't handle enter key presses without extra effort. Did you know that in OSX, spacebar also clicks a button—but not a link?
That's an accessibility requirement for OSX buttons; it's a user expectation. How about right clicks? Notice how links have an option to open in a new tab, but buttons don't?
You can implement almost all of this from scratch with divs. You can use ARIA, JS, and someday AOM. But avoid it.
HTML is not perfect. It's been around a long time. It doesn't have newer UI patterns we need. Certain elements are hard to style. It never included all the semantics needed for accessibility in the first place.
That's why ARIA exists, to supplement HTML semantics in an app. So in addition to learning the HTML elements available, you will need to learn the ARIA to add landmarks, labels, or connect different elements.
(* I note we'll talk more about accessibility later.)
Ultimately, you're the only one who can make sure to put the button in a form, use type submit, and add labelledby or owns references.
Component libraries will help with some things, but not everything! For example, our button component adds a layer around the HTML button and handles (whatever things it handles).
(* I note we'll talk about components to use later.)
There's a lot to learn over time, but you've already started, so just take it step by step.
(I send a list of helpful links, a mix of introductory tutorials, articles about specific topics I mentioned, and persistent references like MDN and WCAG. I may or may not copy and paste it here later.)
(* The additional chat related to app distribution builds is when I talk about how HTML parses and "streams." How CSS, JS, images, etc. load and fit in. Why the separation of concerns is how it is. Client side DOM updates. What bundlers do. The additional chat related to accessibility talks about disabilities. Interaction modalities—digital UIs are physical. The practical need for ARIA related to screen readers. Testing it.)