A Quality Checklist I Use for This Personal Website

A public note-to-self for the next time I change this site, so the Precise Alloy-based blog stays fast, responsive, accessible, secure, and useful offline.

A personal website can get messy in very ordinary ways. One experiment becomes a permanent feature, one temporary style becomes part of the design system, and one small performance regression becomes the new normal because nobody wrote down what normal should be.

This page is mostly a note for myself. When I publish a new page, change the theme, or add a feature, this is the list I want nearby before I call the work done.

The frontend of this website is based on the Precise Alloy template. One quiet goal of this site is to keep acting as a live example of the template's quality bar. If someone is curious about the template, or a little skeptical of it, I can point them here and let the page speak through the usual tools.

Some of these targets are stricter than many personal sites need. That is partly because I enjoy this kind of work, and partly because a personal site is a nice place to be a little unreasonable in the useful direction.

There is a practical benefit for me too. Treating this blog as a small workshop teaches lessons I can carry into larger websites and projects, where small quality decisions have a much wider effect.

What This Checklist Is For

The goal is simple: when I touch a public page, I want it to stay fast, responsive, accessible, secure, valid, useful offline, readable in light and dark mode, and printable when the content makes sense on paper.

I use the checklist in three ways.

As a design constraint before I build a component.
As a regression check after I change the theme, templates, or frontend assets.
As a publishing checklist before I treat a page as finished enough to leave alone.

That last part matters. Finished enough does not mean perfect forever. It means the page has survived the basic checks that protect readers from avoidable friction.

PageSpeed and SEO

For public, indexable pages, I aim for a perfect PageSpeed Insights result.

100 Performance
100 Accessibility
100 Best Practices
100 SEO

A perfect score is not the same thing as a perfect website. It does not prove that the writing is good, the design is pleasant, or the page is useful. It is simply a useful signal that the page has avoided many common mistakes: oversized assets, render-blocking work, missing metadata, unlabeled controls, and fragile browser features.

For pages that intentionally use noindex, the SEO score may be lower because PageSpeed reports Page is blocked from indexing. That is not a failure when the page is deliberately hidden from search. The important part is that the exception is intentional, not accidental.

When a score drops, I do not want to argue with the thermometer. I want to understand what changed, then decide whether the change is worth it.

Browsers and Devices

Performance only helps if the page still feels good in the browser someone actually has open. For this site, that means normal pages should work well on mobile, tablet, and desktop, in Chrome, Firefox, and Safari.

The page should render correctly, be easy to use, and keep navigation comfortable at each size. Reading a post should not require a perfect desktop viewport, a lucky browser choice, or a suspicious amount of pinching and zooming.

For more formal project work, the Browsers and Devices page is the reference I adapt. For this blog, the same thinking applies in a lighter way: make common devices feel ordinary, not like edge cases.

Accessibility

Every public page should meet WCAG 2.2 level AA. I treat that as the baseline, not the stretch goal.

This includes the checks that are easy to miss when a page looks fine visually:

Keyboard navigation works from start to finish.
Focus indicators are visible and not hidden behind sticky UI.
Headings, landmarks, and reading order make sense without the visual layout.
Images have useful alt text when they carry meaning.
Decorative images stay quiet instead of being announced as noise.
Forms have labels, instructions, validation messages, and recovery paths.
Motion and interaction patterns do not punish people who use different input methods.

I keep a separate WCAG Checklist for more systematic reviews. Automated tools are helpful, but they are not the whole review. A page can pass an automated scan and still be awkward, confusing, or tiring to use.

The practical rule is this: if I cannot use the page comfortably with a keyboard and a screen reader-friendly structure, the page needs another pass.

Compliance

Every rendered page should pass Nu Html Checker with no errors and no warnings.

That may sound fussy for a personal site, but valid HTML is one of the cheapest forms of maintenance. Browsers are forgiving, which is kind of them, but that forgiveness can hide broken nesting, duplicate id values, invalid ARIA, obsolete attributes, and form markup that only works by accident.

The checker has to run against the rendered page, not only the Markdown source or template partial. Page generators, shortcodes, syntax highlighting, and injected assets can all change the final HTML. The browser and assistive technologies only receive the final output, so that is the version that matters.

For this site, warnings should not be waved away casually. If a warning appears, I either fix it or understand exactly why it is acceptable. The preferred state is nicely boring: zero errors, zero warnings, nothing mysterious blinking on the dashboard.

Security

I want the site to keep the maximum score available in the Mozilla HTTP Observatory report. At the time of writing, that means 130 out of 100.

Security on a personal site is not dramatic most days. There is no checkout flow, no admin area for visitors, and no customer database hiding behind the homepage. Still, the browser receives HTML, CSS, JavaScript, images, fonts, and third-party connections. That is enough surface area to deserve discipline.

The important requirements are:

A strict Content Security Policy that avoids unsafe-inline and unsafe-eval wherever possible.
No mixed content and no unnecessary third-party requests.
Subresource Integrity for stable third-party assets when a CDN is genuinely needed.
Sensible Referrer-Policy, Permissions-Policy, and related security headers.
No frontend feature that requires weakening the security headers just to make it work.

The last point is the one that tends to matter in real life. A clever widget is not clever if it forces the whole site to relax its security posture. If a feature needs unsafe exceptions, it needs a better implementation or a very clear reason to exist.

Offline Access

The site should remain useful when the network disappears. Any page a reader has visited recently should stay accessible without internet and render the same way it did online, including the CSS, images, fonts, and scripts needed for that page.

For pages that have not been visited while the internet was available, the site should show a friendly No Internet page instead of a normal browser error or a broken half-rendered document. Offline support should feel calm: either the cached page opens correctly, or the fallback explains what happened.

I keep a small service worker cache information page for checking what the current browser has stored. It is mostly a debugging helper, but it makes the offline behavior easier to reason about when I change caching rules.

Light and Dark support

All pages and UI components should fully support light and dark themes.

The default theme is light.
The site detects the user's system preference.
The user can change the theme manually.
The selected theme persists across visits.

Theme support is not just swapping a background color. Every component state has to survive both modes: default, hover, focus, active, disabled, selected, expanded, collapsed, loading, and error.

Both light and dark themes should meet WCAG 2.2 level AAA color contrast where color contrast applies. That is stricter than the general AA accessibility target, but color is one of the easiest things to regress during theme work. A button that is readable in light mode and faint in dark mode is not a theme. It is just a small trap wearing branding.

The theme also has to work in print. The printed page should use the light theme, even if the reader normally browses in dark mode.

Print & PDF Ready

Every normal content page should be ready for print and PDF export.

This matters more than it sounds. People save pages for review, share PDFs with colleagues, archive technical notes, and read long-form content away from the browser. A page that looks good on screen but falls apart in print still has one more job to do.

On Chrome/Firefox, click Menu ⟶ Print (or press Ctrl+P), then:

Uncheck Headers and footers so the browser does not inject its own page title, URL, and timestamps.
Check Background graphics so the exported PDF keeps the colors and visual treatment provided by the site.

Then press Save. Verify that:

The generated PDF looks clean and intentional.
The page's main content renders correctly.
The page uses the light theme.
Code blocks, tables, images, and callouts are not cut off.
Links remain visible enough to be useful.
Navigation, controls, and decorative screen-only UI do not dominate the printed document.

Interactive pages may need a simplified print view rather than a perfect copy of the screen. That is fine. The requirement is not that every interaction becomes printable. The requirement is that printing does not produce a broken document.

The Review Flow

When I make a meaningful change to the site, the review flow should be roughly this:

Build the site locally and fix any build errors.
Check the rendered page, not only the source file.
Run PageSpeed Insights after the page is available in a preview or production environment.
Check the page across mobile, tablet, and desktop widths in Chrome, Firefox, and Safari.
Review accessibility with automated tools, keyboard testing, and the WCAG Checklist.
Validate the rendered HTML with Nu Html Checker.
Check Mozilla HTTP Observatory after deployment when headers are involved.
Test recently visited pages offline, plus the No Internet fallback for pages that are not cached.
Test light mode, dark mode, and persisted theme selection.
Export a PDF from Chrome and Firefox when the page is meant to work as a document.

The more a change touches shared templates, navigation, typography, theme tokens, JavaScript, or page metadata, the more seriously this flow matters. A small template change can affect hundreds of pages. Websites are extremely good at making small changes look local right up until they are not.

The companion Non-Functional Requirements page has a more tool-focused checklist for frontend work. This blog post is the personal version: the reminder I want nearby when I work on my own site.

What This Is Not

This is not a promise that every page will stay perfect forever. Websites age. External tools change their scoring. Browser behavior changes. I change my mind about design details. Occasionally, a page will probably fail a check because reality enjoys having hobbies.

The point is not to pretend quality never drifts. The point is to make drift visible.

If a page falls below the bar, that should be a known decision, a tracked problem, or a temporary exception. It should not be a surprise I discover months later while trying to change something unrelated.

Final Thought

These notes make the site a little slower to change sometimes, but much easier to trust.

That trade-off is worth it to me. I would rather publish fewer pages that are fast, responsive, accessible, secure, valid, offline-ready, theme-aware, and printable than keep adding pages that slowly teach the site to accept avoidable problems.

And if someone wants to check whether the site really lives up to this list, that is the nice part: most of the tools are public. They can run them against this website and see the result for themselves.