LessonLesson 31 of 34

HTML quality: maintainability, performance, and review

Review a page as a complete experience: meaningful markup, resilient loading, accessible interaction, and maintainable source.

Advanced5 min readLearn · Practice · Review

Published by HTML Code Runner · AI-assisted material · Independent editorial review pending · Editorial policy

On this page

Learning objectives

Build a repeatable review process; distinguish validity from usability; prioritize measurable performance and maintainable structure.

Prerequisites

Complete semantic layout, forms, images, metadata, and accessibility basics.

Write for the next change

Readable source lowers the cost of fixing a page. Use consistent indentation, quote attribute values, and keep related content together. Choose descriptive classes and stable IDs. Avoid large blocks of commented-out obsolete markup that make it unclear which implementation is active. Version control is a better history tool than leaving old interfaces in comments.

Semantic structure should survive a redesign. A navigation region remains nav when its color changes; a product description remains article or a suitable section when its columns change. Keep presentation in CSS and behavior in focused scripts. This does not forbid small inline demonstrations, but production repetition deserves a reusable structure.

Review the whole loading experience

A page can have valid HTML and still be slow, confusing, or unstable. Reserve space for images and embeds. Avoid downloading large offscreen media without a reason. Load scripts with a strategy appropriate to their dependencies, and remove libraries that provide little value for the task. Measure on a realistic device and connection rather than assuming a fast development machine represents the audience.

Performance work should preserve usability. Removing labels to save a few bytes or replacing native controls with inaccessible custom graphics is a poor trade. Optimize the expensive parts first: oversized images, unnecessary requests, long main-thread work, and repeated database or network operations.

Progressive enhancement keeps essential content and actions understandable when optional scripts fail. A useful link remains a link, a form has a deliberate submission design, and important article text is available in the document. Test the actual fallback instead of assuming it works because you used a semantic tag.

Make quality checks specific and repeatable

Use a conformance checker to find invalid nesting, duplicate IDs, and disallowed attributes. Then test meaning and behavior manually: heading order, keyboard navigation, visible focus, labels, errors, captions, and alternative text. Automated accessibility tools identify some defects but cannot decide whether a description conveys the right information.

Verify every internal link and important resource in the deployed environment. File case, rewrite rules, base URLs, and caching can differ from local development. Inspect status codes and response types rather than relying only on whether the browser appears to recover.

Before release, review privacy and security boundaries appropriate to the page. Untrusted text must be output safely; forms need server validation; embeds need deliberate permissions. Record the tested browser versions and known limitations. A review report should state what was checked, not make a blanket claim that no problem can exist.

Working example

<main id="main">
<article aria-labelledby="guide-title">
<h1 id="guide-title">Plan a library visit</h1>
<p>Check opening times and access information before you travel.</p>
<h2>Opening times</h2>
<p>Tuesday to Saturday, 10:00 to 18:00.</p>
<a href="access.html">Read step-free access information</a>
</article>
</main>

Another example

<img src="reading-room.jpg" width="1200" height="800" alt="Reading desks beside large windows" loading="lazy">
<script src="site.js" defer></script>

Expected output

The first example has an understandable outline and descriptive link even without CSS. The second reserves image space and defers a classic external script; it still requires real local resources and appropriate placement in the page.

Common mistakes

Do not equate zero validator errors with a fully accessible product. Do not apply lazy loading to every image without considering initial visibility. Do not add ARIA to compensate for a needlessly complicated structure before trying simpler native markup.

Accessibility and browser notes

Include keyboard-only testing and substantial zoom in routine review. Check more than the default state: open drawers, invalid forms, empty search results, long labels, and slow loading can reveal problems hidden by a polished homepage screenshot.

Practice

Review a page containing an unlabeled field, duplicate card IDs, and a click here link. Write a corrected small fragment.

Review the solution and reasoning
<label for="catalogue">Search catalogue</label><input id="catalogue" name="q" type="search">
<article class="card"><h2>Opening hours</h2><a href="hours.html">View opening hours</a></article>
<article class="card"><h2>Membership</h2><a href="membership.html">Read membership requirements</a></article>

The field has a native label, repeated cards use a class instead of duplicate IDs, and each link describes its destination. These changes improve structure before any visual styling is applied.

Related lessons

Specifications and further reading

One more skill in your toolkit.

Finished the explanation and exercise? Save your progress.