Test and Validate Your Site

Build a practical pre-launch QA workflow for validation, Lighthouse, browser testing, accessibility, and content review.

Why Validation Matters

Validation is the process of checking whether a site is built on reliable foundations. The browser is forgiving, which is useful while you are learning, but it also means mistakes can hide. A missing closing tag might still render. An invalid CSS rule might be ignored silently. A button might look fine while being difficult to reach with a keyboard.

A validation pass helps you catch those issues before deployment. It also changes the way you think about quality. Instead of asking, "Does it look okay on my screen?", you start asking, "Does this hold up for different users, browsers, devices, and conditions?"

The Layers of a Good QA Pass

A useful pre-launch check looks at several layers. Each layer answers a different question about the site.

This matters because no single tool can judge the whole site. A validator can find invalid markup. Lighthouse can point out common performance and accessibility risks. Your own manual testing can notice whether the navigation feels clear and whether the content makes sense.

Validate the HTML

HTML validation checks whether your markup follows the rules the browser expects. The most common tool is the W3C Markup Validation Service. You can validate a public URL, upload a file, or paste HTML directly.

When validating a local project, you may need to copy the rendered HTML from the browser or validate the built page after deployment preview. For a beginner or intermediate static site, focus on fixing clear errors first.

Warnings need judgement. Some are useful. Some are more contextual. Errors are a better first priority because they usually mean the browser is repairing your document behind the scenes.

Check the CSS

CSS validation is less dramatic than HTML validation because invalid CSS is often ignored one declaration at a time. That can make CSS mistakes easy to miss. A typo in a property name, a missing unit, or an unsupported value might simply fail without breaking the whole stylesheet.

.menu-card {
  margin-top: 24;      /* Missing unit */
  colour: #222;        /* UK spelling is invalid in CSS */
  display: grid;
}

In this example, the browser ignores the invalid declarations and keeps the valid ones. That is helpful, but it can also make you wonder why a style "doesn't work." DevTools will usually show invalid or crossed-out declarations in the Styles panel.

Run a Lighthouse Audit

Lighthouse is built into Chrome DevTools. It checks common issues across performance, accessibility, best practices, and SEO. It is useful because it gives you a broad scan quickly.

For learning projects, Lighthouse is most helpful when you treat it as a set of clues rather than a score to worship. A perfect score is not the goal. A page that loads reasonably, uses meaningful content, supports keyboard navigation, and avoids obvious accessibility failures is much more important.

Run Lighthouse against a production-like version when possible. Local development servers, browser extensions, and throttling settings can affect results. If a score looks strange, rerun the audit in an incognito window with extensions disabled.

Manual Browser Testing

Automated tools are useful, but they do not experience the site like a person. Manual browser testing checks the real path through the page.

For a site like Black Swan Bistro, manual testing should include:

• clicking every navigation link on every page
• checking that the current page is clear in the navigation
• testing mobile, tablet, and desktop widths
• checking that images load and do not distort
• submitting or testing forms safely, if forms exist
• using the keyboard to move through links and controls

When you find an issue, write it down as a symptom first. For example: Menu link wraps awkwardly at 375px is more useful than fix CSS. A clear symptom gives you a better starting point for debugging.

Accessibility and Content Checks

A pre-launch pass should include basic accessibility and content review. This does not replace a full accessibility audit, but it helps catch common blockers before real users hit them.

These checks also prepare you for the SEO and deployment lessons. Search engines, assistive technologies, and social previews all rely on clear structure and meaningful content. A tidy page is easier for both people and machines to understand.

A Reusable Pre-launch Checklist

Here is a checklist you can adapt for future projects:

You do not need to fix every non-critical warning before launch. You do need to understand what remains and make a deliberate decision. That is the difference between skipping quality and managing quality.

Recap

Testing and validation turn "it looks done" into "I have checked the important parts." HTML validation, CSS inspection, Lighthouse audits, manual browser testing, accessibility checks, and content review each catch different kinds of problems.

The strongest workflow is not complicated. Check the structure. Check the styles. Check the experience. Check the launch details. Write down what you found, fix the blockers first, and retest.