Lesson 1, Topic 1
In Progress

Lesson 1.13: Accessibility Basics

Lesson 1.13 – Accessibility Basics | Knowledge Pillars HCCS
Unit 1 · Lesson 1.13

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.

HTML & CSS Web Design ~40 Minutes Beginner

Lesson Objectives

  • Understand what web accessibility is and why it matters for every developer
  • Write effective alt text 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:

1 in 4
U.S. adults live with some form of disability
2.2B
People worldwide have a vision impairment
96%
Of top homepages have detectable accessibility failures
+SEO
Accessible HTML also improves search engine rankings
💡 The Curb-Cut Effect: Features built for accessibility almost always benefit everyone. Captions help in noisy environments. Good heading structure helps all readers skim. High-contrast text is easier for everyone to read in sunlight. Accessibility is good design.

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:

Perceivable

Users must be able to perceive all information and UI — nothing is invisible to all senses. Example: providing alt text for images.

Operable

All functionality must be accessible via keyboard, not just mouse. Example: links and buttons work with Tab and Enter keys.

Understandable

Content and navigation must be clear and predictable. Example: using plain language, logical heading order, and consistent navigation.

Robust

Content must work with current and future assistive technologies. Example: using valid, semantic HTML that any browser or screen reader can parse.

📌 For this lesson, we'll focus on the practical HTML techniques that satisfy POUR — alt text, heading hierarchy, semantic structure, and introductory ARIA. These four areas cover the majority of accessibility errors found on real websites.

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

Rule 1: Be Specific & Meaningful

Describe what the image communicates in context. Avoid vague phrases like "image" or "photo." A screen reader already announces it as an image.

Rule 2: Match the Purpose

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.

Rule 3: Decorative = Empty Alt

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.

❌ Poor Alt Text
<img src="images/photo.jpg"
     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.
✅ Good Alt Text
<img src="images/photo.jpg"
     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. ✓
<!-- Profile photo: describe the person --> <img src="images/profile.jpg" alt="Jordan Smith, a web design student"> <!-- Linked logo: describe the destination --> <a href="index.html"> <img src="images/logo.png" alt="My Website — Home"> </a> <!-- Decorative divider: empty alt, no meaning added --> <img src="images/divider.png" alt="">
⚠️ Never omit alt entirely — 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:

❌ Broken Hierarchy
<h1>My Page</h1>
<h3>About Me</h3>
↑ Skipped H2 — jumps from H1 to H3.
<h2>Hobbies</h2>
<h1>Contact</h1>
↑ Second H1 — only one allowed per page.
✅ Correct Hierarchy
<h1>My Page</h1>
<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
💡 The "Skip Navigation" Test: If a screen reader user presses the key to jump to headings, would they get a clear, logical outline of your page? If yes, your heading structure is good. If they'd land in confusing or out-of-order places, it needs fixing.

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.

Screen Reader Simulation
Press Play to hear how a screen reader navigates by landmarks… ▶ Banner landmark — "Jordan Smith's Personal Webpage — heading level 1" ▶ Navigation landmark — "Main navigation — list of 3 items: Home, About, Contact" ▶ Main landmark — "About Me — heading level 2" ▶ Complementary landmark — "Aside — Favorite Quote" ▶ Content information landmark — "Footer — Copyright 2025 Jordan Smith"
<!-- Each semantic element creates a named landmark for screen readers --> <header> <!-- "banner" landmark --> <h1>Jordan Smith</h1> <nav> <!-- "navigation" landmark --> <ul>...</ul> </nav> </header> <main> <!-- "main" landmark --> <section> <h2>About Me</h2> <p>...</p> </section> </main> <aside> <!-- "complementary" landmark --> <h2>Favorite Quote</h2> </aside> <footer> <!-- "contentinfo" landmark --> <p>&copy; 2025</p> </footer>
✅ Good news: If you've been building your personal webpage with semantic HTML since Lesson 1.7, you've already been creating a more accessible page. Accessibility and good HTML structure go hand in hand.

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.

💡 The First Rule of ARIA: "Don't use ARIA if you can use native HTML instead." A <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-label: names an element with no visible text label --> <button aria-label="Close navigation menu">✕</button> <!-- aria-labelledby: connects a section to its visible heading --> <section aria-labelledby="hobbies-heading"> <h2 id="hobbies-heading">My Hobbies</h2> <p>I enjoy coding and photography.</p> </section> <!-- aria-hidden: hides a decorative icon from screen readers --> <p><span aria-hidden="true">📧</span> Email me at jordan@example.com</p>
📌 For your personal webpage: You don't need complex ARIA at this stage. The three most useful ones right now are 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.

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.

❌ Inaccessible Link Text
<p>To see my work,
<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.
✅ Accessible Link Text
<p>To see my work,
<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. ✓
⚠️ "Click here," "read more," and "learn more" are among the most common accessibility failures on the web. They are meaningless without surrounding text — and screen reader users navigating by links won't have that surrounding text. Always describe where the link goes or what it does.

Student Activity

✨ Accessible

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.

  1. Audit your images — check every <img> tag. For each image, ask: Does it have an alt attribute? 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!
  2. 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!
  3. Connect your sections to their headings using aria-labelledby. Find each <section> in your page. Give the heading inside it an id, then add aria-labelledby to the section pointing to that id:
    <section aria-labelledby="about-heading"> <h2 id="about-heading">About Me</h2> <p>...</p> </section>
    💾 Save!
  4. 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!
  5. 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-labelledby when there's already a visible heading or label on the page you can point to. Use aria-label when 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-label to 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.

HTML5 Structure Tags & Nesting Headings & Paragraphs Head & Meta Tags Hyperlinks DOCTYPE Semantic HTML HTML Attributes HTML Comments HTML Entities File Organization HTML Validation Accessibility Basics