Semantic, Responsive and Accessible Interfaces

Introduction

Modern web interfaces must do more than display information. They must communicate structure to browsers, assistive technologies, search engines, and human users working across devices, languages, and abilities. This chapter presents an integrated approach to interface development based on semantic HTML, modern CSS, responsive design, reusable component styling, progressive enhancement, internationalization, and WCAG accessibility principles.

The central design principle is that structure, presentation, behaviour, and content should be related but not unnecessarily dependent. HTML should express meaning; CSS should control presentation; JavaScript should add behaviour where it improves the experience. A standards-compliant interface remains understandable and usable when screen size, input method, language, network quality, or assistive technology changes.

Learning Objectives

After studying this chapter, you should be able to:

• distinguish semantic HTML from presentational markup;
• construct pages using meaningful landmarks and document structure;
• apply responsive layouts using flexible dimensions, media queries, and modern CSS layout systems;
• design reusable components with predictable states and maintainable styles;
• explain progressive enhancement and graceful degradation;
• apply internationalization principles to content and layout;
• evaluate interfaces against WCAG principles and common accessibility practices;
• test interfaces using automated tools, keyboard interaction, screen readers, and manual inspection.

1. Semantic HTML as an Information Model

Semantic HTML uses elements according to their meaning rather than their visual appearance. A nav element identifies a navigation region, while a div merely creates a generic container. Semantic markup improves maintainability, accessibility, search interpretation, and collaboration because the document communicates its purpose directly.

Important structural elements include:

Semantic elements do not automatically make an interface accessible. A badly ordered heading structure, missing form labels, or inaccessible custom widget can still create serious problems. Semantics are a foundation, not a complete accessibility solution.

Document Structure and Headings

Headings create an outline that helps users scan content and navigate with assistive technology. A page should normally have one clear h1, followed by headings whose levels reflect nesting. Heading levels should not be selected merely because a particular font size is desired; CSS controls visual size.

<main>
  <h1>Student Services</h1>
  <section aria-labelledby="enrolment-heading">
    <h2 id="enrolment-heading">Enrolment</h2>
    <p>Find information about registration and course changes.</p>
    <h3>Changing a course</h3>
    <p>Submit a change request before the published deadline.</p>
  </section>
</main>

A heading should describe the content that follows it. Empty headings, skipped levels used without structural reason, and headings used only for visual emphasis weaken the document model.

Links and Buttons

A link moves the user to another resource or location. A button performs an action in the current interface. Using a div with a click handler instead of a button often removes keyboard behaviour, focus handling, and the correct accessibility role.

<a href="/courses">Browse courses</a>
<button type="button" aria-expanded="false">Show details</button>

Link text should remain meaningful when read separately. “Download the accessibility guide” is more informative than “click here.” Buttons should state the action they perform, such as “Save profile” or “Close dialog.”

Forms and Data Tables

Every form control needs an accessible name, usually supplied by a label. Instructions and error messages should be associated with the relevant control.

<label for="email">University email</label>
<input id="email" name="email" type="email"
       autocomplete="email" required
       aria-describedby="email-help">
<p id="email-help">Use your institutional email address.</p>

Tables should represent tabular relationships, not page layout. Use caption, th, and appropriate header associations. A simple table may use scope="col" and scope="row"; complex tables may require id and headers relationships.

2. Accessibility as Inclusive Design

Accessibility concerns the ability of people with visual, auditory, motor, cognitive, speech, and neurological disabilities to perceive, operate, understand, and interact with digital content. WCAG 2.2 organises guidance around four principles:

1. Perceivable: information and controls can be perceived in suitable forms.
2. Operable: interface functions can be operated through available input methods.
3. Understandable: information and operation are clear and predictable.
4. Robust: content works with current and future user agents and assistive technologies.

WCAG conformance levels are A, AA, and AAA. In many institutional and commercial contexts, Level AA is the practical target, but conformance claims require evaluation against the applicable success criteria and the complete page experience.

Perceivable Content

Do not communicate meaning through colour alone. A required field may use an icon or text in addition to colour. Text alternatives should convey the purpose of informative images; decorative images should have an empty alt attribute.

<img src="campus-map.svg" alt="Map showing the library north of the main entrance">
<img src="decorative-rule.svg" alt="">

Captions or transcripts should support prerecorded audio and video where applicable. Text must remain readable when zoomed, and content should not become unusable when users increase spacing or magnification.

Operable Interfaces

All functionality should be available from a keyboard unless the task inherently requires another form of input. Keyboard focus must be visible, and focus should not be trapped unexpectedly. Avoid removing the browser’s focus indicator without providing a stronger replacement.

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
}

Do not create keyboard traps. A modal dialog may temporarily constrain focus, but it must provide a logical entry point, keep focus inside while open, close through an accessible control, and return focus to the triggering element.

Touch targets should have sufficient size and separation. WCAG 2.2 includes a target-size criterion with defined exceptions; designers should also consider device diversity, tremor, zoom, and one-handed operation.

Understandable and Robust Interfaces

Use clear labels, consistent navigation, predictable interaction, and useful error recovery. Set the document language:

<html lang="en">

Use valid, well-formed HTML and native controls whenever possible. Native controls provide extensive behaviour and accessibility support at low implementation cost. Custom widgets require careful management of roles, states, keyboard interaction, focus, and announcements.

ARIA should supplement HTML, not replace it. The principle “no ARIA is better than bad ARIA” is practical: an incorrect role or state can mislead assistive technology users. Common states include aria-expanded, aria-selected, aria-checked, and aria-current; each must reflect the actual interface state.

3. Responsive Design

Responsive design allows content and layout to adapt to viewport size, orientation, input capability, zoom, and user preferences. It is not simply the practice of making a desktop page narrower. It begins with flexible content and a hierarchy that remains useful at every size.

A responsive page normally includes:

<meta name="viewport" content="width=device-width, initial-scale=1">

Without an appropriate viewport declaration, mobile browsers may simulate a wider desktop viewport, causing unexpected scaling.

Fluid Layouts

Use relative units such as %, rem, em, vw, and ch where they express relationships. Use px when a fixed dimension is appropriate, such as a border width. Avoid designing around one device model.

.page {
  width: min(100% - 2rem, 72rem);
  margin-inline: auto;
}

.prose {
  max-inline-size: 70ch;
}

min(), max(), and clamp() support fluid constraints. For example, font-size: clamp(1.1rem, 1rem + 1vw, 1.6rem) establishes a minimum, flexible preferred value, and maximum. This is a CSS sizing expression, not a universal readability guarantee; it must be tested at zoom levels and with real content.

Grid and Flexbox

Flexbox is generally suitable for one-dimensional alignment, such as a row of controls. Grid is suitable for two-dimensional relationships, such as cards arranged in columns and rows.

.card-list {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
  gap: 1.5rem;
}

This pattern allows columns to adapt without requiring a breakpoint for every device width. However, automatic layout does not eliminate the need to test long headings, translated text, zoom, and unusual content.

Media Queries and User Preferences

Breakpoints should be based on where the content needs adjustment, not on the names of devices. A mobile-first approach begins with a simple layout and adds enhancements as available space permits.

.navigation-list {
  display: flex;
  flex-direction: column;
}

@media (min-width: 48rem) {
  .navigation-list {
    flex-direction: row;
    gap: 1rem;
  }
}

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    scroll-behavior: auto !important;
    transition-duration: 0.01ms !important;
  }
}

Other useful preference queries include prefers-contrast, forced-colors, and prefers-color-scheme. These preferences should be respected without making content or controls disappear.

4. Component Styling and Design Systems

A component is a reusable unit combining structure, styles, behaviour, and states. Examples include buttons, alerts, cards, navigation menus, dialogs, and form fields. Good components have clear responsibilities, predictable inputs, and documented states.

A button component may have the following states:

• default;
• hover;
• focus-visible;
• active;
• disabled;
• loading;
• error or destructive variant.

State must not be communicated only through colour. A loading button should expose a meaningful accessible name or status, and it should not allow duplicate submissions unintentionally.

CSS custom properties help establish design tokens:

:root {
  --color-primary: #005fcc;
  --color-text: #1b1b1b;
  --space-2: 0.5rem;
  --space-4: 1rem;
  --radius: 0.4rem;
}

.button {
  background: var(--color-primary);
  color: white;
  border: 0;
  border-radius: var(--radius);
  padding: var(--space-2) var(--space-4);
}

Tokens improve consistency and permit controlled theme changes. They do not guarantee adequate colour contrast. Contrast must be evaluated for the actual text size, weight, foreground, background, and state. Designers should also account for forced-colour modes and users who apply custom styles.

Component boundaries should not obscure semantics. A card component can contain an article, heading, image, and link, but a generic wrapper should not be assigned excessive ARIA roles merely to make it appear sophisticated.

5. Progressive Enhancement

Progressive enhancement starts with a functional baseline and adds presentation and behaviour in layers:

1. semantic HTML provides content and basic interaction;
2. CSS improves layout, readability, and visual hierarchy;
3. JavaScript adds richer interaction, validation, asynchronous updates, and personalisation.

For example, a search form should submit to a server using ordinary HTML before JavaScript replaces submission with an asynchronous request. If JavaScript fails, the essential task should still be possible.

Progressive enhancement improves resilience under slow networks, blocked scripts, browser differences, and assistive technology use. It is not identical to graceful degradation. Graceful degradation often begins with an advanced experience and provides a fallback; progressive enhancement begins with a robust baseline and adds capability.

Enhancement must also preserve accessibility. A script-generated menu should retain keyboard access, focus management, and meaningful states. Client-side validation should supplement, not replace, server-side validation because the server remains responsible for security and data integrity.

6. Internationalization and Localization

Internationalization prepares a product for multiple languages, regions, scripts, calendars, numbering systems, and cultural conventions. Localization adapts it for a particular locale.

Important practices include:

• declare the primary language with lang;
• avoid embedding user-visible text in images;
• externalize translatable strings;
• allow text expansion and contraction;
• use locale-aware date, time, number, and currency formatting;
• support right-to-left scripts through logical CSS properties;
• avoid assumptions about names, addresses, phone numbers, and order;
• permit user input in appropriate scripts and character sets.

Logical properties reduce directional assumptions:

.panel {
  margin-inline: auto;
  padding-inline: 1rem;
  border-inline-start: 0.25rem solid var(--color-primary);
}

For right-to-left content, use language metadata and test the complete interface rather than simply mirroring a screenshot. Direction affects punctuation, icons, tables, focus order, and mixed-language content.

Do not build dates by concatenating strings. Locale-aware APIs such as Intl.DateTimeFormat should be used in JavaScript, while server-side applications should also apply locale-aware formatting. Time zones must be explicit when an event has real-world scheduling consequences.

7. Testing and Evaluation

Accessibility and responsiveness cannot be established by code inspection alone. A practical evaluation combines:

Automated testing is valuable but incomplete. It can identify missing labels or invalid attributes, but it cannot reliably judge whether alternative text is meaningful, whether focus order is logical, or whether instructions are understandable.

A useful test scenario is task-based: “Find the deadline, change the notification preference, and submit the form using only the keyboard.” Record completion, errors, unnecessary steps, focus location, and feedback. This produces stronger evidence than merely checking whether a tool reports zero errors.

8. Applied Case: Accessible Course Registration Portal

The following is an illustrative case.

Background

A university replaced a desktop-oriented course registration portal with a responsive web application. The initial prototype used clickable div elements, fixed-width tables, colour-coded availability, and a JavaScript-only registration flow.

Problem

Keyboard users could not reliably open course details. Screen readers announced course rows without useful headings. On small screens, the timetable required horizontal scrolling, and users with colour-vision deficiencies could not distinguish available, waitlisted, and closed courses. Translated course titles also overflowed their cards.

Analysis

The project team mapped tasks rather than screens. Core tasks were: search for a course, inspect prerequisites, select a section, review conflicts, and submit registration. Each task was evaluated with semantic HTML, keyboard-only navigation, zoom, a screen reader, and a narrow viewport.

Approach and Solution

The team used a real form for searching, a semantic table for timetable relationships, and buttons for selection actions. Availability was conveyed through text and an icon in addition to colour. Each course row received a meaningful accessible name, and error messages were connected to the relevant controls.

The layout used Grid for course cards and logical properties for spacing. At narrow widths, nonessential columns were reorganised into labelled blocks rather than forcing users to scroll through an unreadable table. The server retained a normal submission path, while JavaScript added instant filtering and conflict feedback. Focus moved to the results heading after a search and returned to the triggering control when a dialog closed.

Outcome

Keyboard completion became possible for all core tasks. Screen-reader users received course names, status, and available actions in a predictable order. The interface remained usable at increased zoom and in a right-to-left test locale. The team also reduced support requests because validation messages explained how to correct errors.

Learning Points

The main improvement did not come from a single CSS trick. It resulted from treating semantics, interaction, responsive layout, internationalization, and accessibility as one design problem. Native controls reduced implementation effort, while testing exposed failures that automated tools alone would not have found.

9. Professional, Ethical, and Governance Considerations

Accessibility is both a quality obligation and, in many jurisdictions, a legal responsibility. Organisations should define ownership, testing processes, procurement requirements, and remediation priorities. Accessibility statements should be honest and supported by evidence; claiming conformance without adequate evaluation creates ethical and legal risk.

Developers should avoid dark patterns such as confusing consent controls, inaccessible cancellation paths, or interfaces that pressure users into sharing unnecessary data. Personalisation and analytics must respect privacy, provide appropriate notice, and avoid inferring sensitive characteristics without legitimate justification.

AI-assisted coding can generate useful markup and test cases, but generated code may introduce invalid ARIA, insecure event handling, inaccessible custom controls, or culturally inappropriate text. Human review, standards knowledge, and user testing remain necessary. AI should assist professional judgement rather than replace it.

Best-Practice Checklist

Before release, verify that:

• the document has a meaningful title, language, landmark structure, and heading hierarchy;
• native HTML controls are used wherever possible;
• every form control has a visible, associated label;
• keyboard focus is visible and never becomes trapped unexpectedly;
• colour is not the sole carrier of meaning;
• images have appropriate alternative text;
• layout works at narrow widths, zoom, and reflow;
• motion respects user preferences;
• content can expand for translation;
• right-to-left and long-text scenarios have been tested;
• JavaScript enhances rather than monopolises essential tasks;
• automated and manual accessibility tests have both been performed;
• errors are understandable, recoverable, and associated with their controls.

Chapter Summary

Semantic HTML gives an interface a meaningful structural model that benefits users, browsers, search systems, and developers. Landmarks, headings, links, buttons, forms, and tables should be selected according to purpose rather than appearance. Accessibility is organised by the WCAG principles of perceivable, operable, understandable, and robust content, but conformance requires practical testing as well as correct markup.

Responsive design uses flexible constraints, Grid, Flexbox, media queries, and user-preference queries to support varied screens and conditions. Component styling becomes maintainable when structure, states, tokens, and responsibilities are explicit. Progressive enhancement preserves a functional baseline before adding richer behaviour. Internationalization requires language metadata, locale-aware formatting, flexible layouts, logical properties, and testing with different scripts and conventions. Finally, professional interface quality depends on automated checks, keyboard and assistive-technology testing, user-centred evaluation, ethical governance, and continuous improvement.

Key Terms

Semantic HTML: HTML whose elements communicate the meaning and structure of content.

Landmark: A programmatically identifiable major region, such as main or nav.

Responsive design: Design that adapts content and layout to different conditions and devices.

Progressive enhancement: Building a robust baseline and adding richer presentation or behaviour in layers.

Graceful degradation: Providing a fallback for an advanced experience when features are unavailable.

WCAG: Web Content Accessibility Guidelines for accessible web content.

Perceivable: Capable of being presented to users in forms they can perceive.

Operable: Usable through available interaction methods.

Robust: Compatible with user agents and assistive technologies.

ARIA: Attributes that communicate roles, states, and properties to assistive technologies.

Accessible name: The programmatic name announced for a control or other object.

Focus: The current keyboard interaction position.

Flexbox: A CSS layout system for one-dimensional arrangements.

Grid: A CSS layout system for two-dimensional arrangements.

Design token: A named reusable value for design decisions such as colour or spacing.

Internationalization: Preparing a system to support multiple languages and locales.

Localization: Adapting a system for a particular language, region, or culture.

Logical property: A CSS property that responds to writing direction and flow, such as margin-inline.

Reflow: Rearrangement of content so it remains usable at increased zoom or narrow widths.

Progressive disclosure: Revealing additional information or controls as needed without hiding essential meaning.

Review Questions

Short Answer Questions

1. What is the difference between a semantic element and a generic div?
2. Why should a button be used instead of a clickable div for an action?
3. Name the four WCAG principles.
4. What is the purpose of the viewport meta element?
5. Why is automated accessibility testing insufficient by itself?

Long Answer Questions

1. Explain how semantic HTML, headings, landmarks, and form labels contribute to accessibility.
2. Describe a mobile-first responsive strategy using Grid, Flexbox, relative units, and media queries.
3. Compare progressive enhancement with graceful degradation and give a practical example.
4. Explain how component states and design tokens improve maintainability without guaranteeing accessibility.
5. Discuss the relationship between internationalization, logical CSS properties, and responsive layout.

Analytical / Application Questions

1. A registration form uses red borders to indicate errors but provides no text message. Analyse the accessibility problems and propose a corrected design.
2. A custom dropdown works with a mouse but not with a keyboard or screen reader. Identify the likely failures and recommend whether to replace it with a native control or redesign it.
3. Design a testing plan for a multilingual course portal that must support keyboard users, mobile users, zoom, right-to-left text, and reduced-motion preferences.

Multiple Choice Questions with Answers

Question 1

Which element is most appropriate for a group of major site-navigation links?

A. nav

B. aside

C. figure

D. footer

Correct Answer: A. nav

Question 2

What is the primary purpose of a visible :focus-visible style?

A. To improve search ranking

B. To show the current keyboard interaction position

C. To disable mouse input

D. To replace alternative text

Correct Answer: B. To show the current keyboard interaction position

Question 3

Which CSS layout system is generally designed for two-dimensional row-and-column relationships?

A. Float

B. Positioning

C. Grid

D. Filter

Correct Answer: C. Grid

Question 4

What does progressive enhancement begin with?

A. A JavaScript-only interface

B. A functional baseline using fundamental web technologies

C. A desktop-only layout

D. A visual mock-up without content

Correct Answer: B. A functional baseline using fundamental web technologies

Question 5

Which attribute supplies the primary language of an HTML document?

A. charset

B. dir

C. locale

D. lang

Correct Answer: D. lang

Question 6

Why should colour not be the only way to communicate course availability?

A. Colour always increases page size

B. Some users cannot distinguish the colours or may not perceive them

C. CSS cannot apply colour to text

D. Screen readers always remove colour

Correct Answer: B. Some users cannot distinguish the colours or may not perceive them

Question 7

Which control is normally the correct semantic choice for submitting a form?

A. span

B. button

C. section

D. label

Correct Answer: B. button

Question 8

What is the main purpose of aria-describedby in the form example?

A. To associate supplementary instructions with a control

B. To change the document language

C. To create a visual border

D. To submit the form automatically

Correct Answer: A. To associate supplementary instructions with a control

Question 9

Which practice best supports internationalized layouts?

A. Hard-coding left and right margins everywhere

B. Embedding all text in images

C. Using logical properties such as margin-inline

D. Assuming all names have the same format

Correct Answer: C. Using logical properties such as margin-inline

Question 10

Why must automated accessibility testing be supplemented by manual testing?

A. Automated tools cannot detect any HTML errors

B. Manual testing is required only for colour selection

C. Automated tools cannot reliably judge every issue, such as meaningful alternative text and logical task flow

D. Manual testing makes semantic HTML unnecessary

Correct Answer: C. Automated tools cannot reliably judge every issue, such as meaningful alternative text and logical task flow