HTML presentation preflight checklist before you publish

An HTML presentation preflight checklist is a pass/fail review of the exact artifact you plan to host, followed by a second review of the returned reader URL. It catches missing assets, local paths, private data, broken controls, narrow-screen overflow, sandbox restrictions, and version mistakes before a client receives the link.

Download the machine-readable Markdown checklist to run this review in a pull request, an agent workflow, or a manual release packet. The article below explains why each gate exists and what evidence should close it.

What does an HTML presentation preflight checklist cover?

A hosting preflight covers the boundary between a finished deck and a dependable reader link. It does not replace editorial review of the story, numbers, claims, or design. Run those checks first; then use this checklist on the final package that will actually leave the creator's machine.

The release has two test objects:

Testing only the source project misses build-output errors. Testing only the hosted link makes it harder to distinguish an incomplete artifact from a delivery-policy problem. Keep the two results separate.

This page is the release checklist. For the broader decision about specialized presentation publishing versus a general static host, start with the HTML presentation hosting guide. For exact Slidesfly upload steps, use the publishing Proof Pack.

Record the release identity first

Before checking boxes, record:

• source revision or commit;
• framework and version, or “plain HTML”;
• exact build command;
• output path and entry file;
• expected hosting path or base URL;
• file count and uncompressed size;
• intended visibility and audience;
• reviewer, browser, viewport, and date.

Without that identity, “tested” can accidentally refer to a different build from the one that is uploaded.

Freeze the publishable output

The publishable artifact is the result of the build, not the project folder that produced it. Freeze one output directory or one self-contained HTML file, then run every remaining check against that unchanged object.

Identify the correct output by framework

Reveal.js distinguishes a browser-only basic setup from the full project setup and notes that features such as external Markdown require a local web server in development. Read the Reveal.js installation documentation before deciding which files form the release.

Slidev's hosting documentation generates a static SPA in dist/, supports a deployment --base, and offers --without-notes when presenter notes should not enter a public build. Publish the built output, not slides.md and the source tree.

Marp CLI can export static HTML, but its official security note says browser-based conversion blocks local-file access by default and warns that enabling it is not secure for untrusted Markdown. Treat a conversion warning as a failed preflight until the referenced asset is deliberately packaged or removed.

Make the output immutable during review

If a title, chart, dependency, or image changes, rebuild and restart the affected checks. Do not quietly patch files inside dist/ after recording the build command; that makes the release hard to reproduce and easy to overwrite on the next build.

Check every file and path the deck needs

Most “works on my machine” failures come from the browser resolving a URL differently after the deck moves. Inspect the final HTML, CSS, JavaScript, and asset tree—not just the first slide.

Path checks

• Entry file is named and located where the selected host expects it.
• Every relative image, font, stylesheet, script, media, and Markdown reference exists inside the package.
• No reference begins with file://, a local home directory, a drive letter, localhost, 127.0.0.1, or a development-server port.
• Root-relative paths such as /assets/chart.svg are used only when the deck will be served from the origin root.
• Parent paths such as ../media/video.mp4 do not escape the uploaded bundle.
• Filename case matches exactly; a case-insensitive laptop can hide a production mismatch.
• Remote URLs use HTTPS, are reachable without the creator's session, and are intentional runtime dependencies.

MDN explains that the <base> element changes how all relative URLs resolve and that, without it, the document URL becomes the base. A deck that moves from / to /d/abc/ can therefore resolve assets/chart.svg, /assets/chart.svg, and ../assets/chart.svg to three different locations.

Do not add <base href="/"> as a reflexive fix. It can break in-page anchors and make the deck depend on origin-root files the presentation host does not own. Prefer a framework's build-time base setting or package paths that remain correct at the final reader location.

A safe first-pass scan

The commands below list filenames containing common machine-only references. They deliberately use -l so a terminal transcript does not print a possible secret value:

rg -l 'file://|localhost|127\.0\.0\.1|/Users/|/home/|[A-Za-z]:\\Users\\' ./publish-output
rg -l 'api[_-]?key|authorization|bearer|client[_-]?secret|private[_-]?key' ./publish-output

These patterns produce false positives and cannot prove that a package is secret-free. Review each matching file, then inspect the browser Network panel for requests that the static scan cannot see.

Remove secrets, notes, and private data

Anything inside client-delivered HTML should be treated as readable by a recipient. Hiding a value in JavaScript, a source map, a comment, or an unlisted URL does not make it private.

Check the final package for:

• API keys, access tokens, cookies, authorization headers, private URLs, and signed download links;
• customer names, email addresses, speaker notes, internal comments, hidden slides, and appendix data not intended for this audience;
• .env files, repository metadata, source maps, test fixtures, console logs, and debug panels;
• embedded datasets that contain more rows or columns than the visible chart;
• forms or calls to action that send data to an endpoint without a reviewed privacy path;
• third-party fonts, images, video, or libraries whose license does not permit this delivery.

An unlisted link reduces normal discovery; it does not authenticate a viewer. Passwords, expiry, allowlists, and private storage can reduce exposure when implemented correctly, but they do not make it acceptable to embed reusable credentials in the deck.

Test navigation and accessibility

An HTML deck is an interactive web document. A reviewer must be able to reach every slide and every essential control without relying on one device or one input method.

Navigation pass

1. Reload the deck and confirm the intended opening slide.
2. Move forward and backward through every slide with the documented keyboard controls.
3. Repeat with visible buttons or a single-pointer interaction.
4. Repeat on a touch device or touch emulation.
5. Open and close fullscreen, overview, notes, modal, or code-demo controls that the audience needs.
6. Follow internal anchors and external links, then return to the correct slide.
7. Confirm the last slide does not trap focus or send the viewer to an unintended page.

W3C's keyboard guidance requires a keyboard interface for functionality that does not inherently depend on a movement path. The W3C accessible presentations checklist also calls out readable text, sufficient contrast, accessible materials, and careful use of motion.

Accessibility pass

• document language and page title describe the deck;
• headings and landmarks follow a meaningful order outside the visual layout;
• informative images and charts have text alternatives or an equivalent explanation;
• focus is visible and follows the presentation sequence;
• controls have accessible names and usable target sizes;
• text and meaningful graphics retain sufficient contrast;
• auto-advance, flashing, looping media, and nonessential motion can be paused or reduced;
• captions or transcripts exist for essential audio and video;
• the deck remains understandable at browser zoom and with custom text spacing.

Automated accessibility scans can find missing attributes and some contrast failures. They cannot judge slide order, chart meaning, keyboard traps, alternative explanations, or whether a screen reader announces the current slide coherently. Keep a manual pass.

Test responsive rendering and slide integrity

A deck can pass at 1440 pixels and fail on a phone, an embedded reader, a projector, or a browser with different fonts. Test the production-shaped artifact at representative widths and heights.

At every size, inspect the cover, a dense slide, a chart or table, an image-heavy slide, an interactive slide, and the final call to action. Then scan every remaining slide for overflow, cropped text, overlapping footers, missing backgrounds, unreadable labels, and layout shifts while fonts or media load.

Do not accept “the deck is fixed at 16:9” as a reason to skip narrow testing. The host may place that canvas inside a responsive reader, and a recipient may open it before entering fullscreen.

Test network and sandbox behavior

Local preview and hosted execution have different origins, headers, network access, and browser permissions. Use the browser Network and Console panels on the final reader URL.

Check for:

• 404 or 403 responses, redirects to sign-in, incorrect MIME types, and mixed HTTP/HTTPS content;
• CORS failures from APIs, fonts, images, video, or storage origins;
• JavaScript exceptions on the first interaction, not only at page load;
• remote libraries or datasets that require cookies, referrers, IP allowlists, or a private network;
• forms, downloads, popups, clipboard, fullscreen, storage, and top-navigation behavior;
• service workers or caches that keep an earlier deck version visible;
• third-party requests that disclose the reader URL or audience context unexpectedly.

A sandboxed reader may intentionally block popups, top navigation, same-origin storage, downloads, or forms. MDN's iframe reference documents how sandbox tokens selectively restore capabilities. Do not weaken isolation to make one unreviewed interaction pass; first decide whether the deck genuinely needs that capability.

If you are evaluating the hosting system rather than one artifact, use the untrusted HTML hosting security model and its evidence-bearing review checklist. This preflight verifies a release; it does not audit the platform architecture.

If the presentation only works while the creator is signed in to another service or connected to a private network, the reader link is not independently deliverable. Package the dependency, replace it with a deliberate public source, or document the audience prerequisite.

Verify the hosted link as a recipient

The final gate starts after the host returns a URL. Open that exact link in a private window, another browser profile, or another device without the publisher's cookies.

External-view checklist

1. Confirm the URL, page title, deck title, and intended visibility.
2. Load the first slide on a clean session and watch for authentication or consent barriers.
3. Navigate first → middle → last → previous with keyboard and touch.
4. Verify critical images, fonts, charts, media, code, and external links.
5. Recheck a narrow viewport and fullscreen.
6. Confirm the visible revision matches the frozen artifact identity.
7. Copy the link from the reader and open the copied value in a second clean session.
8. Record the reviewer, time, browser, viewport, result, and unresolved limits.

For Slidesfly, the browser and CLI flows both return a reader URL. The Quickstart shows the shortest workflow; the framework compatibility guide records current artifact limits; and the security architecture explains the reader boundary.

A clean external view proves that the tested URL rendered under the tested conditions. It does not prove that every future browser will behave identically, that an unknown viewer is a qualified recipient, or that the presentation created business value.

Release record

Store a compact result beside the source or release ticket:

artifact: <commit or sha256>
build: <exact command>
output: <path and entry file>
hosted_url: <reader URL>
visibility: <public, unlisted, protected, or private>
tested_at: <ISO timestamp>
tested_with: <browser, viewport, input methods>
result: PASS | FAIL
limits: <known constraints or none observed>
reviewer: <name or accountable team>

The record makes a later update reviewable. If the artifact or access policy changes, create a new result instead of editing the old PASS.

Frequently asked questions

Should I test the source project or the built HTML presentation?

Test the built artifact you will upload. Source-project preview is useful during creation, but it can hide missing production assets, an incorrect base path, excluded files, notes, source maps, and environment-dependent requests. Record the build command and output path so another reviewer can reproduce the same package.

Is opening the HTML file locally enough?

No. A file:// preview uses different URL, origin, network, and browser-policy behavior from an HTTPS reader. It is a useful first check for a self-contained file, followed by an HTTP preview and the final hosted URL in a clean browser session.

How do I find missing assets before publishing?

Inspect the final file tree, search HTML and CSS for local or parent paths, then use the browser Network panel to load every slide. A static scan finds declared references; runtime navigation is still required because JavaScript can create URLs only after an interaction.

Should all presentation assets be embedded in one HTML file?

Not always. A single file reduces packaging mistakes and works well for small plain-HTML decks. A complete multi-file build can be better for framework output, large media, caching, and maintainable source. Choose deliberately and verify that the selected host accepts the whole artifact.

Does an unlisted reader URL pass the privacy check?

Not by itself. Unlisted usually means omitted from normal discovery; anyone with the link may still open it. Remove secrets first, then choose and verify password, allowlist, expiry, or authenticated access when the audience requires it.

What should make the preflight fail immediately?

Fail immediately for embedded credentials, unauthorized data, unresolved missing files, required controls that cannot be operated, a deck that breaks at the target viewport, an incorrect live revision, or a visibility policy that does not match the audience. Do not downgrade these to notes.

If the frozen artifact passes, continue to the exact publish-and-verify workflow. Keep the completed Markdown checklist with the source revision so an update can be tested against the same boundary.

Continue with the Quickstart or browse all HTML presentation publishing guides.