—HTML Series · Post 10: HTML Accessibility Basics
Accessibility Basics:
HTML Is for Humans
This is not optional. If your site doesn't work for everyone, it doesn't work. Here are the a11y fundamentals every developer needs from day one.
Let's get one thing straight before we go any further: accessibility is not a bonus feature. It's not something you "add later." It's not a nice-to-have for extra credit. It's a fundamental part of writing HTML.
When you write HTML, you're not just writing for Chrome on a MacBook. You're writing for screen readers, keyboard-only users, people with low vision, motor impairments, cognitive differences — the full spectrum of how humans interact with the web. And if your HTML doesn't account for that, your HTML is broken.
The good news? Accessibility starts with things you already know. Proper headings, good alt text, correct form labels — most of a11y is just writing good HTML in the first place.
a11y is the numeronym for "accessibility" — the "a", then 11 letters, then "y." You'll see it everywhere in the dev world. It's pronounced "ally," which is fitting because that's exactly what accessible code makes you.
The Six Things You Need to Learn Right Now
You don't need to become a WCAG expert overnight. But you do need to understand these six fundamentals. They cover the vast majority of accessibility issues beginners create — and they're all fixable with basic HTML.
1. Proper Heading Order
Headings aren't just big text. They create the document outline — a structural map of your page that screen readers use to let users jump between sections. Think of headings like a table of contents: h1 is the title, h2s are chapters, h3s are sub-sections.
Don't pick a heading level because of how it looks. Pick it based on the document structure. If you want smaller text, use CSS — that's what it's for. Headings communicate hierarchy, not font size.
2. Alt Attributes — Describe What Matters
The alt attribute on images is one of the most important accessibility features in HTML. Screen readers read it aloud. Search engines index it. And if the image fails to load, the alt text shows up instead.
Write alt text like you're describing the image to a friend over the phone. Be specific and useful. "Photo" tells them nothing. "Woman in a hoodie writing code at a coffee shop" paints the picture.
And if the image is purely decorative (a line, a pattern, a background shape), use alt="" — an empty alt tells the screen reader to skip it entirely.
3. Labeling Forms Properly
Every form input needs a <label>. Not a placeholder. Not a <div> next to it. A real, linked label. This is how screen readers know what each input is for, and it's how users with motor impairments can click the label to focus the input.
The for attribute on the label must match the id on the input. That link is what makes it accessible. And as a bonus, it makes the label clickable — click the text, and the input gets focused. Better UX for everyone.
Placeholders disappear as soon as the user starts typing. That means once someone is filling out your form, they can't see what the field was asking for. Always use a visible <label>. Placeholders are optional hints, not replacements.
4. ARIA Basics — The Intro Level
ARIA stands for Accessible Rich Internet Applications. It's a set of attributes you can add to HTML elements to provide extra information to assistive technology. Think of ARIA as a way to annotate your HTML with instructions for screen readers.
But here's the most important ARIA rule you'll ever learn:
Don't use ARIA if native HTML does the job. A <button> is always better than <div role="button">. A <nav> is always better than <div role="navigation">. Native HTML has built-in keyboard support, focus management, and screen reader announcements. ARIA adds none of that — it only adds labels.
That said, there are times when ARIA is genuinely useful. Here are the most common attributes you'll encounter as a beginner:
You don't need to memorize every ARIA attribute right now. Just remember: use native HTML first, and reach for ARIA only when you need to fill in gaps that HTML can't cover on its own.
5. Keyboard Navigation Awareness
Not everyone uses a mouse. Some people navigate entirely with a keyboard — Tab to move between interactive elements, Enter or Space to activate them, Escape to close things, arrow keys to navigate within components.
If your site requires a mouse to use, it's broken for these users. Here's what you need to know:
Here's a quick accessibility check you can do right now: open your project in the browser, put your mouse away, and try to navigate your entire page using only Tab, Enter, and Escape. Can you reach every button? Every link? Every form field? If not, you've found your first accessibility bug.
6. Avoiding Div Misuse
We covered <div> in the last post — and this is where it connects directly to accessibility. A <div> has zero semantic meaning. Screen readers don't announce it. It doesn't receive keyboard focus. It has no built-in behavior.
So when you use a div as a button, you're creating something that looks clickable but isn't accessible:
The same applies to links. If something navigates the user to a new page, it should be an <a> tag — not a div or span with a click handler.
Use <div> for layout and grouping. Never for interaction. If a user clicks it, tabs to it, or activates it — it needs to be the right element. Buttons are buttons. Links are links. Let HTML do its job.
I once built an entire contact form with zero labels. Every input just had a placeholder. I thought it looked "cleaner."
Then I tested it with a screen reader and every single field announced as "edit text." Just… "edit text." Over and over. No indication of what any field was actually for.
I added labels that same day. Took me five minutes. Should've been there from the start. Lesson learned — accessible doesn't mean ugly. It means usable. 💯
The Big Picture: HTML Is for Humans and Machines
Here's the thing about accessibility that changes how you think about HTML: you're not just writing code for browsers to render. You're writing instructions that get interpreted by a whole ecosystem of tools — screen readers like NVDA and VoiceOver, search engine crawlers, browser extensions, voice assistants, and more.
When you write semantic, accessible HTML, you're giving all of those tools the information they need to present your content correctly. When you write div soup with no labels, no headings, and no structure, you're saying "figure it out" — and most of the time, they can't.
Accessibility isn't about checking boxes for compliance. It's about recognizing that the web was built to be universal — and writing HTML that lives up to that promise.
🔨 Mini Build: A11Y Audit Your Last Project
Open your most recent HTML project and run through this accessibility checklist:
The Bottom Line
Accessibility isn't advanced. It isn't a specialization. It's HTML fundamentals. If you use the right heading order, write meaningful alt text, label your forms correctly, understand basic ARIA, respect keyboard navigation, and stop misusing divs — you're already ahead of a huge percentage of the web.
HTML was designed to be accessible from the start. The only way it becomes inaccessible is when developers break it. So don't break it.
Write HTML for humans. All of them.
You've made it through 10 posts of HTML fundamentals — from document structure to accessibility. You now have a solid foundation in how HTML actually works, not just what tags exist. The next step? Start building. Take everything you've learned and create something real. You've got the knowledge — now go ship it.
