Semantic HTML, Accessibility and Content Design

Introduction and Context

A web page is not merely a visual arrangement of text, images, and controls. It is a document interpreted by several audiences: sighted users, keyboard users, screen-reader users, search engines, browser features, assistive technologies, and future developers maintaining the code. Semantic HTML provides the structural meaning that allows these audiences to understand and use content reliably.

Accessibility is the practice of designing and implementing digital products so that people with diverse abilities can perceive, operate, understand, and interact with them. Content design complements accessibility by determining what information users need, how it should be organized, and how language and interaction can reduce confusion. These concerns are not optional refinements. They are part of professional quality, inclusive participation, legal compliance in many jurisdictions, and ethical software development.

This chapter focuses on semantic landmarks, meaningful document structure, WCAG principles, keyboard accessibility, alternative text, labels, and the careful use of ARIA. It also considers inclusive content decisions and the responsibilities of developers when technology affects people differently.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish semantic HTML from presentational markup;
• construct pages using meaningful headings and landmark elements;
• explain the four WCAG principles: perceivable, operable, understandable, and robust;
• design keyboard-accessible links, buttons, forms, and custom controls;
• write useful alternative text and accessible form labels;
• apply ARIA only when native HTML cannot express the required meaning;
• organize content for clarity, inclusion, and task completion;
• evaluate an interface for accessibility, ethical risks, and practical usability.

1. Semantic HTML as Meaningful Structure

HTML is a markup language for describing the structure and meaning of a document. Semantic elements communicate purpose. For example, <nav> identifies a navigation region, <button> identifies an interactive command, and <article> identifies a self-contained composition. By contrast, a page built mainly from <div> elements may look correct but provide little information about relationships and purpose.

Semantic HTML benefits several systems at once:

• Assistive technology: screen readers can announce landmarks and control types.
• Keyboard interaction: native controls provide expected focus and activation behavior.
• Search and indexing: meaningful structure helps automated systems interpret content.
• Maintenance: developers can understand the page without guessing the purpose of every element.
• Responsive design: structure remains meaningful when visual layout changes.

Semantics do not replace visual design. CSS controls appearance, while HTML establishes document meaning and interaction. A useful principle is: use HTML for structure and meaning, CSS for presentation, and JavaScript for behavior that cannot be achieved through native HTML and CSS alone.

1.1 Common Semantic Elements

A page can contain multiple headers or footers when they belong to different sections. In contrast, a document should normally contain one <main> element because it identifies the unique central content. A <section> should not be used merely as a generic styling wrapper; it should represent a meaningful thematic group and generally have a heading.

1.2 Headings and Hierarchy

Headings form an outline that enables scanning and navigation. A page title normally uses <h1>, major topics use <h2>, and subordinate topics use <h3> and lower levels. Heading levels should reflect logical nesting, not desired font size. CSS can make an <h2> visually smaller or larger without changing its structural meaning.

Avoid choosing a heading because it looks attractive, such as using <h4> for a large title. Avoid skipping levels solely for visual reasons. A document may move from <h2> to <h4> in unusual cases, but consistent hierarchical structure is easier for users and tools to interpret.

A heading should describe the content that follows. “More information” is less useful than “Application deadlines,” because the latter communicates the topic when a user navigates through a list of headings.

1.3 Landmarks

Landmarks are regions that allow users of assistive technology to move directly to major areas. Native elements such as <header>, <nav>, <main>, <aside>, and <footer> create implicit landmarks. If multiple regions have the same kind, such as two navigation areas, provide distinguishing accessible names when appropriate.

A simple structure might be:

<body>
  <header>
    <a href="/">Northstar College</a>
    <nav aria-label="Primary navigation">
      <a href="/courses">Courses</a>
      <a href="/support">Support</a>
    </nav>
  </header>

  <main>
    <h1>Certificate in Full Stack Programming</h1>
    <section aria-labelledby="overview-heading">
      <h2 id="overview-heading">Programme overview</h2>
      <p>...</p>
    </section>
  </main>

  <footer>
    <p>Contact the college support team.</p>
  </footer>
</body>

The aria-label in this example is useful because it distinguishes a navigation region. It does not replace the links or create functionality; it names the region.

2. WCAG and the Four Principles

The Web Content Accessibility Guidelines (WCAG) provide internationally influential guidance for accessible web content. Their central model is often summarized by four principles, abbreviated as POUR.

Perceivable

Information and controls must be presented in ways users can perceive. Examples include:

• text alternatives for meaningful images;
• captions and transcripts for multimedia;
• sufficient color contrast;
• content that remains usable when text is enlarged;
• layouts that do not depend exclusively on color.

Operable

Users must be able to operate controls and navigate content. Important practices include:

• full keyboard access;
• visible focus indicators;
• adequate time for tasks or a way to extend time;
• avoiding content that causes harmful flashing;
• clear navigation and sufficient target size.

Understandable

Content and operation should be predictable and comprehensible. Use plain, specific language; consistent navigation; meaningful error messages; instructions before users need them; and form feedback that identifies how to correct a problem.

Robust

Content should work with current and future user agents and assistive technologies. Valid HTML, correct native semantics, progressive enhancement, and careful ARIA implementation support robustness.

WCAG conformance levels are commonly described as A, AA, and AAA. A project should identify its applicable legal, institutional, or contractual target rather than claiming that accessibility is achieved by passing a single automated test. Automated tools are valuable, but they detect only some issues. Human testing remains necessary.

3. Keyboard Accessibility

Many users navigate without a mouse. This includes people with motor impairments, screen-reader users, power users, and people using alternative input devices. Every interactive function should be available from the keyboard, and the order of movement should be logical.

Native HTML controls provide substantial behavior automatically. A native button can receive focus, respond to keyboard activation, and expose its role to assistive technology. A clickable <div> does not provide these properties automatically.

Prefer:

<button type="button" id="show-details">Show details</button>

over:

<div class="button" onclick="showDetails()">Show details</div>

If a custom control is genuinely necessary, developers must implement focusability, an appropriate role, keyboard events, state communication, and visual focus. This is difficult to implement reliably, which is why native controls are preferred.

Focus and Focus Order

A focused element must have a visible indicator. Removing the browser outline without providing an equally clear replacement makes keyboard navigation difficult. CSS should preserve a strong focus style:

:focus-visible {
  outline: 3px solid #0b63ce;
  outline-offset: 3px;
}

The DOM order should generally match the visual and reading order. Avoid positive tabindex values such as tabindex="5"; they create unpredictable focus sequences. tabindex="0" can place a custom element in the normal sequence, while tabindex="-1" allows programmatic focus without adding it to ordinary tab navigation. These attributes should be used sparingly.

Keyboard accessibility also includes dialog behavior, menus, accordions, and dynamic content. When a modal dialog opens, focus should move into it, remain appropriately contained while it is active, and return to the initiating control when it closes. A visible close control and an understandable name are essential.

4. Images and Alternative Text

Alternative text communicates the purpose or information of an image when the image cannot be perceived. It is not a universal visual description; it is a contextual replacement.

<img src="campus.jpg" alt="Students collaborating around a laptop in the programming lab.">

Useful decisions include:

• Informative image: describe the information relevant to the page.
• Functional image: describe the action, such as alt="Search" for a search icon that submits a search.
• Decorative image: use empty alternative text, alt="", so assistive technology can ignore it.
• Complex image: provide a concise alternative and a nearby detailed explanation or data table.
• Image containing text: reproduce the text in the alternative or, preferably, provide real HTML text.

Do not write “image of” unless that fact is important. Do not repeat a caption immediately in alternative text when doing so creates unnecessary duplication. The correct alternative depends on context: a photograph of a lecturer may need a person’s name on a staff page but may be decorative beside an already identified biography.

5. Accessible Forms and Labels

Forms are a frequent source of exclusion. Every control needs a programmatically associated label, clear instructions, and useful error feedback.

<form>
  <div>
    <label for="email">College email address</label>
    <input id="email" name="email" type="email" autocomplete="email" required>
  </div>

  <button type="submit">Subscribe</button>
</form>

The for value on the label must match the input’s id. Placeholder text is not a replacement for a label because it disappears during entry, often has low contrast, and is not a reliable instruction. Use fieldset and legend for related choices:

<fieldset>
  <legend>Preferred contact method</legend>
  <label><input type="radio" name="contact" value="email"> Email</label>
  <label><input type="radio" name="contact" value="phone"> Phone</label>
</fieldset>

Error messages should identify the affected field, explain the problem in plain language, and state the correction. For example, “Enter a valid email address, such as [email protected]” is more useful than “Invalid input.” When errors appear dynamically, they must also be made available to assistive technology without moving focus unexpectedly or causing confusion.

6. ARIA: Use It Carefully

Accessible Rich Internet Applications (ARIA) provides roles, states, and properties for communicating interface behavior when HTML alone is insufficient. ARIA can improve custom widgets, but it cannot repair poor structure automatically.

Three practical rules are especially important:

1. Prefer native HTML. Use <button> rather than a <div role="button">.
2. Do not change native meaning unnecessarily. Incorrect roles can make a control less accessible.
3. If ARIA is used, implement the complete interaction pattern. A role is not behavior.

For example, aria-expanded="false" can communicate that a button controls a collapsed region. JavaScript must update it to true when the region opens, and the controlled content must be correctly associated, often with aria-controls. The button must still be keyboard operable.

ARIA attributes should not be used to hide important information or to create a false claim of accessibility. aria-hidden="true" can remove content from the accessibility tree while leaving it visible, so applying it to meaningful content is dangerous. Testing should include the accessibility tree, keyboard use, screen readers where available, and different browser combinations.

7. Content Design for Inclusion

Accessible code can still communicate poorly. Content design asks what users are trying to accomplish and how information should be presented to support that goal.

Clarity and Plain Language

Use familiar words, short paragraphs, descriptive headings, and direct instructions. Define necessary technical terms. Replace vague instructions such as “Click here” with “Download the enrolment guide.” This improves link navigation because users who list links separately can understand each destination.

Consistency and Predictability

Use the same term for the same concept. If a service is called “Student portal” in one location, do not call it “Learner dashboard” elsewhere without a reason. Keep navigation in a consistent position and ensure controls behave as users expect.

Inclusive Language and Representation

Avoid stereotypes, unnecessary assumptions about gender, family structure, culture, age, disability, literacy, income, or technology access. Provide alternatives when a process assumes a particular device, payment method, language, or physical ability. Do not treat disability as a defect to be hidden; design for participation and autonomy.

Cognitive Load

Break complex tasks into manageable steps, show progress, preserve entered information, and explain consequences before an irreversible action. Avoid dark patterns such as disguised advertisements, confusing opt-outs, forced continuity, or interfaces designed to make cancellation difficult.

8. A Practical Accessibility Evaluation Process

A certificate-level development workflow can include the following sequence:

1. Inspect structure: check headings, landmarks, lists, tables, language declaration, and document order.
2. Use the keyboard: tab through every interactive control; confirm logical order, visible focus, activation, escape behavior, and absence of keyboard traps.
3. Check text and media: review alternative text, captions, transcripts, link names, labels, instructions, and error messages.
4. Check visual presentation: test zoom, reflow, contrast, text spacing, focus visibility, and reliance on color.
5. Run automated tools: use them to identify likely issues, not to declare complete conformance.
6. Test with people and assistive technology: involve users with relevant access needs whenever possible.
7. Document and retest: record the issue, impact, affected users, remedy, and verification result.

A useful audit question is not merely “Does this pass?” but “Can a person complete the task independently, efficiently, and with confidence?”

Applied Case: An Accessible Course Registration Form

Background

This illustrative case concerns a college that publishes an online form for registering for a programming certificate.

Problem

Students reported that the form was difficult to use with a keyboard. Screen readers announced several fields only as “edit box,” the error summary was not noticed, and a decorative banner was read aloud repeatedly. The form also used color alone to identify required fields.

Analysis

Inspection found that labels were visually positioned beside inputs but were not programmatically associated. Clickable <div> elements were used for the “Continue” and “Back” controls. The error message appeared at the top after submission, but focus remained on the submit control. The banner had no alt attribute, so its filename was announced. Required fields were marked only with red text.

Approach and Solution

The development team replaced the custom clickable elements with native buttons, associated every label using matching for and id values, and added required where appropriate. The decorative banner received alt="". Required status was communicated in the label and through the HTML requirement, not by color alone.

The team added a concise error summary with links to invalid fields. After submission, focus moved to the summary, and each field received a specific correction message. The team tested the form with keyboard navigation, browser zoom, a screen reader, and users who had different access needs.

Outcome

Users could complete the form without a mouse, identify each field, and move directly from the error summary to the relevant correction. The redesign also reduced support requests because all users received clearer instructions.

Learning Points

The case demonstrates that accessibility is produced by coordinated structure, behavior, presentation, and content. It also shows why visual inspection alone is insufficient: labels may appear correctly aligned while remaining unavailable programmatically.

Ethical, Legal, and Professional Responsibilities

Accessibility is connected to human rights, equal participation, and professional duty. Many jurisdictions impose accessibility obligations on public services, education providers, or organizations delivering digital services. Exact legal requirements differ by country and sector, so developers should consult applicable laws, procurement rules, institutional policies, and recognized standards such as WCAG.

Ethical practice goes beyond minimum compliance. A product may technically satisfy a checklist while creating exclusion through inaccessible authentication, unnecessary data collection, manipulative consent, or lack of support for low-bandwidth environments. Teams should include accessibility during requirements, design, coding, testing, procurement, and maintenance—not as a final audit.

AI-assisted development introduces additional responsibilities. Generated code may use incorrect ARIA, omit labels, produce biased language, or invent accessibility claims. Developers remain accountable for reviewing, testing, and explaining the code. Automated accessibility scoring should never be treated as proof that real people can use the product.

Contemporary Practice and Best Practices

Modern browsers continue to improve native accessibility, but standards and implementations vary. Responsive interfaces must be tested at different viewport sizes, zoom levels, input methods, and operating systems. Component libraries can improve consistency, but copied components must still be evaluated in their actual context.

The following practices provide a reliable foundation:

• start with semantic HTML and progressive enhancement;
• use native controls whenever possible;
• maintain a logical heading and landmark structure;
• provide meaningful alternative text and real labels;
• preserve visible focus and keyboard operation;
• never rely on color, sound, or motion alone;
• write specific links, instructions, and error messages;
• use ARIA only when native semantics are insufficient;
• test with automated tools and human users;
• treat accessibility defects as product defects, not personal user failures.

Chapter Summary

Semantic HTML expresses the purpose and relationships of content, enabling browsers, assistive technologies, search systems, and developers to interpret a page. Landmarks such as <main>, <nav>, <header>, and <footer> support efficient navigation, while headings create a meaningful hierarchy. WCAG organizes accessibility around perceivable, operable, understandable, and robust content.

Keyboard access requires native controls, logical focus order, visible focus, and careful handling of dynamic interfaces. Images need context-sensitive alternative text, and form controls need programmatically associated labels, instructions, and actionable error messages. ARIA is useful for advanced interfaces but should not replace native HTML or be applied without implementing the associated behavior.

Good content design uses clear language, predictable interaction, inclusive assumptions, and respectful representation. Ethical accessibility work includes testing with people, considering legal obligations, protecting user autonomy, and reviewing AI-generated code rather than trusting automated claims.

Key Terms

Semantic HTML: HTML that communicates the purpose and structure of content.

Accessibility: The design of products usable by people with diverse abilities.

Landmark: A major page region that supports navigation by users and assistive technology.

Assistive technology: Software or hardware that helps people access digital systems.

WCAG: Web Content Accessibility Guidelines for improving web accessibility.

POUR: The four WCAG principles: perceivable, operable, understandable, and robust.

Heading hierarchy: The logical nesting of headings from <h1> through <h6>.

Keyboard accessibility: The ability to operate an interface without a pointing device.

Focus: The current interface element receiving keyboard input.

Alternative text: Text that communicates an image’s relevant purpose or information.

Decorative image: An image that adds no information and should generally have empty alternative text.

Label: Text programmatically associated with a form control to identify its purpose.

Fieldset: An HTML element grouping related form controls.

ARIA: Attributes and roles that communicate accessibility information for web interfaces.

Native control: A built-in HTML control with standard semantics and interaction behavior.

Progressive enhancement: Building a usable basic experience first, then adding enhanced features.

Dark pattern: A design that manipulates users into actions they may not freely choose.

Cognitive load: The mental effort required to understand and complete a task.

Reflow: Rearrangement of content so it remains usable at different sizes or zoom levels.

Accessibility audit: A structured evaluation of accessibility problems and their remedies.

Review Questions

Short Answer Questions

1. What is semantic HTML, and why is it preferable to using generic <div> elements for all page content?
2. Name the four WCAG principles and briefly explain one of them.
3. Why is a native <button> usually preferable to a clickable <div>?
4. What is the difference between informative and decorative images?
5. How is a <label> associated programmatically with an <input>?

Long Answer Questions

1. Explain how landmarks and heading hierarchy support navigation for both sighted users and users of assistive technology.
2. Describe the main requirements for keyboard-accessible interaction, including focus order, focus visibility, and custom controls.
3. Explain the appropriate and inappropriate uses of ARIA, giving practical examples.
4. Discuss how content design contributes to accessibility beyond technical HTML correctness.
5. Describe a systematic process for evaluating the accessibility of a web form.

Analytical / Application Questions

1. A registration page uses red text to mark required fields, placeholder text instead of labels, and a clickable <div> as its submit control. Identify the accessibility problems and propose a corrected design.
2. A website has two navigation regions and several repeated links labelled “Read more.” Analyze the usability problems and recommend semantic and content changes.
3. A developer claims that an automated accessibility score proves a website is accessible. Evaluate this claim and design a more reliable testing approach.

Multiple Choice Questions with Answers

Question 1

Which element identifies the unique primary content of a page?

A. <aside>

B. <main>

C. <footer>

D. <nav>

Correct Answer: B. <main>

Question 2

What is the main purpose of a heading hierarchy?

A. To control font size without CSS

B. To create logical structure for content

C. To make every paragraph bold

D. To replace navigation links

Correct Answer: B. To create logical structure for content

Question 3

Which WCAG principle concerns keyboard operation and visible focus?

A. Perceivable

B. Operable

C. Understandable

D. Robust

Correct Answer: B. Operable

Question 4

What alternative text is generally appropriate for a purely decorative image?

A. alt="Decorative image"

B. alt="image"

C. alt=""

D. No closing image tag

Correct Answer: C. alt=""

Question 5

Which association correctly connects a label to a form control?

A. The label's for value matches the input's id

B. The label's id matches the input's name only

C. The input's placeholder matches the label's class

D. The label is placed in a footer

Correct Answer: A. The label's for value matches the input's id

Question 6

Why should native HTML controls generally be preferred to custom ARIA widgets?

A. Native controls are always visually attractive

B. Native controls provide established semantics and interaction behavior

C. ARIA cannot be used in modern browsers

D. Native controls eliminate the need for content design

Correct Answer: B. Native controls provide established semantics and interaction behavior

Question 7

Which practice best supports keyboard navigation?

A. Removing all focus outlines

B. Using positive tabindex values throughout the page

C. Maintaining logical DOM order and visible focus

D. Making only images focusable

Correct Answer: C. Maintaining logical DOM order and visible focus

Question 8

Which is the clearest link text?

A. Click here

B. More

C. Read this

D. Download the enrolment guide

Correct Answer: D. Download the enrolment guide

Question 9

What is a major limitation of automated accessibility testing?

A. It cannot identify any HTML errors

B. It detects every accessibility problem reliably

C. It detects only some issues and requires human evaluation

D. It can test only printed documents

Correct Answer: C. It detects only some issues and requires human evaluation

Question 10

Which statement best describes an accessible error message?

A. It uses color alone to indicate failure

B. It says only “Invalid input”

C. It identifies the problem and explains how to correct it

D. It disappears immediately after submission

Correct Answer: C. It identifies the problem and explains how to correct it