Lesson 1.13: Accessibility Basics
Accessibility Basics for the Web
Great websites work for everyone — including people who use screen readers, keyboard navigation, or other assistive technologies. Learn the foundational HTML practices that make your pages inclusive from the very start.
Lesson Objectives
- Understand what web accessibility is and why it matters for every developer
- Write effective
alttext for images — and know when to leave it empty - Apply correct heading hierarchy so screen readers can navigate your page
- Use semantic HTML tags to communicate page structure to assistive technologies
- Understand what ARIA is and apply a small set of introductory ARIA attributes
- Audit your personal webpage for common accessibility issues and fix them
What Is Web Accessibility?
Web accessibility means designing and building websites so that all people can use them effectively — including people with visual, auditory, motor, or cognitive disabilities. An accessible webpage works not just with a mouse and eyes, but also with a keyboard, a screen reader, a switch device, or a refreshable Braille display.
This isn't a niche concern. Accessibility touches a significant portion of every audience:
The WCAG Principles — POUR
The international standard for web accessibility is the Web Content Accessibility Guidelines (WCAG), published by the W3C. WCAG organizes all accessibility requirements around four core principles, remembered with the acronym POUR:
Users must be able to perceive all information and UI — nothing is invisible to all senses. Example: providing alt text for images.
All functionality must be accessible via keyboard, not just mouse. Example: links and buttons work with Tab and Enter keys.
Content and navigation must be clear and predictable. Example: using plain language, logical heading order, and consistent navigation.
Content must work with current and future assistive technologies. Example: using valid, semantic HTML that any browser or screen reader can parse.
Pillar 1: Writing Effective Alt Text
The alt attribute on an <img> element provides a text alternative for the image. Screen readers read the alt text aloud in place of the image. It also appears as fallback text when an image fails to load.
Writing good alt text is a skill. It's not about describing the image like a photograph — it's about conveying the purpose or meaning the image provides in context.
📋 The Three Rules of Alt Text
Describe what the image communicates in context. Avoid vague phrases like "image" or "photo." A screen reader already announces it as an image.
If an image conveys data (a chart), describe the data. If it's a functional image (a logo), describe what it links to. If it's a profile photo, describe the person.
If an image is purely decorative and adds no meaning, use alt="". This tells screen readers to skip it silently — which is better than announcing a meaningless description.
alt="image">
Too vague — "image" adds no information.
<img src="images/chart.png"
alt="chart.png">
Filename as alt text — meaningless to a screen reader.
alt="Jordan smiling in front
of a computer">
Specific and descriptive. ✓
<img src="images/chart.png"
alt="Bar chart showing
monthly visitors, peak in July">
Conveys the data, not just the image type. ✓
alt="" (empty) and a missing alt are not the same thing. An empty alt tells the screen reader to skip the image silently. A missing alt causes screen readers to announce the filename instead, which is confusing and unhelpful.
Pillar 2: Heading Hierarchy
Headings are not just visual — they create a navigational outline of your page. Screen reader users commonly navigate by jumping between headings to find what they need, the same way sighted users scan a page visually. If your heading structure is broken, your page becomes very difficult to navigate.
The rules are simple: headings must form a logical, nested hierarchy. Think of it like a book's table of contents:
<h3>About Me</h3>
↑ Skipped H2 — jumps from H1 to H3.
<h2>Hobbies</h2>
<h1>Contact</h1>
↑ Second H1 — only one allowed per page.
<h2>About Me</h2>
No levels skipped. H2 follows H1. ✓
<h2>Hobbies</h2>
<h2>Contact</h2>
Only one H1. Sections are all H2. ✓
The Heading Rules
- One
<h1>per page — it's the title of the entire document - Never skip levels — don't jump from
<h1>directly to<h3> - Choose heading level for structure, not size — use CSS to control visual size, not the heading number
- Headings label sections — every major region of your page should have a heading above it
Pillar 3: Semantic HTML & Page Landmarks
You learned semantic HTML in Lesson 1.7 — tags like <header>, <nav>, <main>, <section>, <aside>, and <footer>. These aren't just for organization — they create landmark regions that screen readers use to help users jump directly to different parts of the page.
Think of landmark regions like a building's directory: "Floor 1 — Lobby, Floor 2 — Offices, Floor 3 — Cafeteria." Without the directory (landmarks), you have to walk every floor to find what you need.
Pillar 4: Introduction to ARIA
ARIA stands for Accessible Rich Internet Applications. It's a set of HTML attributes — all starting with aria- or the role attribute — that you can add to elements to provide additional accessibility information to screen readers when HTML alone isn't enough.
<button> element is already accessible — adding role="button" to a <div> to make it act like one is much harder and error-prone. Use semantic HTML first; reach for ARIA only when native elements fall short.
🔧 The Most Useful Introductory ARIA Attributes
| Attribute | What It Does | Example Use |
|---|---|---|
| aria-label | Gives an element a name that screen readers announce, overriding its visible text (or providing one when there is none) | Labeling an icon-only button: <button aria-label="Close menu">✕</button> |
| aria-labelledby | Points to another element's id to use as this element's accessible name — great for sections that already have a visible heading |
<section aria-labelledby="about-heading"> |
| aria-hidden="true" | Hides the element completely from screen readers — useful for decorative icons or repeated elements that would be noisy to announce | <span aria-hidden="true">🎨</span> |
| role | Explicitly declares what type of element this is to assistive technology. Most HTML elements already have implicit roles — use this only when needed | <div role="alert">Error: field required</div> |
| aria-live | Tells screen readers to announce content when it changes dynamically — useful for things like quiz feedback or status messages | <p aria-live="polite">Score: 4/5</p> |
aria-labelledby on your sections, aria-hidden="true" on purely decorative emoji and icons, and aria-label on any buttons or links whose purpose isn't clear from their text alone.
Accessible Links & Buttons
Links and buttons are the primary way users interact with a webpage. Screen reader users often pull up a list of all links on a page to navigate quickly — which is why link text must be descriptive on its own, without needing surrounding context.
<a href="portfolio.html">click here</a></p>
A screen reader reads "click here" out of context — meaningless.
<a href="about.html">read more</a>
"Read more" about what? Useless in a link list.
<a href="portfolio.html">view my portfolio</a></p>
Clear destination even out of context. ✓
<a href="about.html">learn more about me</a>
Specific and descriptive. ✓
Student Activity
Accessibility Audit — Code Skills Lab
Open your index.html in the Code Skills Lab. Work through each step below to audit and improve the accessibility of your personal webpage.
-
Audit your images — check every <img> tag. For each image, ask: Does it have an
altattribute? Is the alt text meaningful and specific? If it's a decorative image, is the alt empty (alt="")?<!-- Fix: add or improve alt text on every image --> <img src="images/profile.jpg" alt="Your Name, a web design student at HCCS">💾 Save and review! -
Check your heading hierarchy. Scan through your HTML and list every heading tag in order. Verify: there is exactly one
<h1>, no levels are skipped, and headings reflect the actual structure of your content — not font-size preferences.<!-- Good structure: one H1, logical H2 sections, H3 subsections --> <h1>Your Name</h1> <h2>About Me</h2> <h2>My Hobbies</h2> <h2>Contact</h2>💾 Fix any skipped levels or extra H1s, then save! -
Connect your sections to their headings using aria-labelledby. Find each
<section>in your page. Give the heading inside it anid, then addaria-labelledbyto the section pointing to that id:<section aria-labelledby="about-heading"> <h2 id="about-heading">About Me</h2> <p>...</p> </section>💾 Save! -
Add aria-hidden="true" to any decorative emoji or icons. If you've used emoji for decoration (like a bullet point or background decoration), hide them from screen readers so they don't interrupt the reading flow:<!-- Decorative emoji — no meaning, should be hidden --> <p><span aria-hidden="true">🌟</span> My favorite hobby is photography.</p>💾 Save!
-
Review every link on your page. Could a screen reader user understand where each link goes or what it does from the link text alone — without reading the surrounding paragraph? Fix any "click here" or "read more" links to use descriptive text. 💾 Save and do a final review!
🌟 Bonus Challenge — Try a Free Accessibility Checker!
Once your page is published (or using the direct input method), run it through a free automated accessibility checker:
- WAVE by WebAIM:
wave.webaim.org— visual overlay showing exactly where issues are - axe DevTools: free browser extension for Chrome and Firefox that checks any live page
- Google Lighthouse: built into Chrome DevTools (F12 → Lighthouse tab) — generates an accessibility score
Aim for zero errors in the automated checkers. Note: automated tools catch about 30–40% of accessibility issues — the rest require human judgment, which is why understanding the principles matters.
Troubleshooting Tips
-
Not sure what alt text to write for an image? Ask yourself: "If this image didn't load, what text would give the reader the same information?" That's your alt text. For a profile photo, it's your name and context. For a chart, it's the key insight the chart shows.
-
Heading levels look wrong visually after fixing the hierarchy? That's expected — heading levels control document structure, not visual size. Use CSS to make an
<h2>look as large or small as you want. Never choose a heading level based on how you want it to look. -
Unsure whether to use aria-label or aria-labelledby? Use
aria-labelledbywhen there's already a visible heading or label on the page you can point to. Usearia-labelwhen there's no visible text at all (like an icon-only button). -
Have many "Learn More" links that all go to different places? The quickest fix is to add the destination to the link text: "Learn more about my photography" or "Learn more about my education." If the link text must stay short for design reasons, use
aria-labelto provide the full description. -
Want to experience your page the way a screen reader user does? Try navigating your page using only the Tab key (no mouse). Can you reach everything? Does the focus order make sense? This is one of the most eye-opening accessibility tests you can do.
Knowledge Check
1. A developer places a purely decorative star icon (✨) in a heading. Which alt attribute value is most appropriate?
2. A page has the following heading structure: H1 → H3 → H2 → H2. What is wrong?
3. What does the ARIA attribute aria-hidden="true" do?
4. Which of the following link texts is most accessible?
5. What is the "First Rule of ARIA"?
Lesson Checklist
- Understand what web accessibility is and why it matters for all developers
- Know the four WCAG POUR principles: Perceivable, Operable, Understandable, Robust
- Write meaningful alt text for all informational images; use alt="" for decorative ones
- Verified my page has exactly one H1 and no skipped heading levels
- Used semantic landmark elements: header, nav, main, section, aside, footer
- Added aria-labelledby to sections connecting them to their visible headings
- Added aria-hidden="true" to decorative emoji and icons
- Reviewed all link text — no "click here" or "read more" without context
- (Bonus) Ran page through WAVE, axe, or Lighthouse and reviewed the report
🎓 Unit 1 Complete!
You've finished all 13 lessons of Unit 1 — HTML Fundamentals. You now have the foundational knowledge to build well-structured, valid, organized, and accessible webpages from scratch. Unit 2 is next, where you'll construct a full multi-page website using everything you've learned.
