HTML Accessibility

Previously, datalist wired suggestions to one text input. Accessibility is a wider job: make the whole page usable with keyboards, screen readers, zoom, and different contexts. Good HTML — landmarks, labels, alt, headings, real buttons — is the foundation, not a late polish layer.

Why accessibility matters

People browse without a mouse, enlarge text, or hear the page through assistive tech. A chart with no alt is silent; a search box with no label is nameless; a clickable div may never receive keyboard focus. Inclusive markup helps everyone — clearer outlines, better SEO signals from structure, and fewer “mystery controls.” Accessibility is mostly habits you apply while writing HTML, not a separate product.

Direct answer

1) Prefer semantic regions (main, nav, header, footer) and native controls (button, a, labeled inputs).
2) Give every form control a visible <label> tied with for / id.
3) Write meaningful alt for informative images; use empty alt="" only when the image is purely decorative.
4) Keep one clear h1 and nest h2–h3 without wild level skips.
5) Tab through the page: links and buttons must be reachable and operable without a pointer.
6) Add ARIA only when native HTML cannot express the role — fix structure first.

Labeled search with a landmark

A small search strip shows the pattern: a nav with an accessible name, a labeled search field, and a real submit button. Screen readers can announce the region and the control name; keyboard users can Tab to the input and the button.

Reading the search demo

• nav marks a navigation landmark; aria-label disambiguates when several navs exist
• label for="q" + input id="q" gives the field an accessible name
• name="q" is for submit — separate from the accessible name
• type="search" is a native control with expected keyboard behavior
• A real <button type="submit"> is focusable and activatable with Enter/Space
• Compare with last lesson: datalist helped suggestions; here the focus is naming and reachability

Headings, alt text, and a real button

A second snippet sketches article structure: an h1, a nested h2, an informative image with descriptive alt, and a submit-style action as a <button>. This is the opposite of “click here” links and unlabeled charts.

Reading the structure demo

• One h1 sets the page topic; h2 nests under it without skipping to h4
• The chart’s alt states the takeaway, not just “image” or a filename
• Decorative spacers would use alt="" — this chart is informative, so alt is required
• The action uses <button>, not a div with a click handler
• main landmarks the primary content for assistive tech
• Next lesson adds JavaScript; keep these HTML habits when you wire behavior

Choosing what to fix first

• Unnamed fields: add labels before fancy placeholders
• Silent images that carry meaning: write alt that carries the point
• Fake controls: replace clickable div/span with button or a
• Heading soup: restore a logical outline instead of styling with random levels
• ARIA-only patches: if a native element exists, use it; ARIA supplements, it does not forgive bad structure
• Keyboard dead ends: anything you can click must be reachable with Tab and activatable with keyboard

Practice — page-wide habits

1. Copy the search demo; remove the label and Tab with a screen-reader or accessibility tree — then restore for/id.
2. Add a second nav (for example footer links) and give each nav a distinct aria-label.
3. In the structure demo, change the chart alt to empty and note what is lost; restore a meaningful alt.
4. Intentionally skip from h1 to h4, then fix the outline back to h1 → h2.
5. Replace the button with a div that only has a click hint in your mind — then put the real <button> back and Tab to it.
6. Write one sentence: accessibility starts with HTML structure, not ARIA wallpaper.
7. Peek ahead: the next lesson adds a <script> — keep labels and buttons when behavior arrives.

Easy mistakes

• “Click here” links with no surrounding context
• Informative images with missing or empty alt
• Custom clickable divs that ignore keyboard users
• Using heading levels only for visual size
• Treating placeholder text as a substitute for <label>
• Piling ARIA roles onto broken markup instead of fixing semantics
• Forgetting that last lesson’s datalist still needed a label on the input

Summary

• Accessibility is usable structure for more people and more tools
• Landmarks, labels, alt, headings, and native buttons matter
• Keyboard reach is part of the job, not optional
• Prefer solid HTML before heavy ARIA
• Datalist taught one control; this lesson zooms out to the page
• Next: adding JavaScript to HTML pages