Publish a specific recording edition with visitor-controlled playback, an independently reachable matching transcript and a clearly described recovery route. Verify the public file and the whole listening journey after replacement.
Publish the recording, its player and its transcript as one maintained edition. A working editor preview is only one observation. The public visitor needs an understandable way to start listening, the right written alternative and a useful route when playback fails. Those promises should survive a later audio replacement.
This guide follows a fictional museum publishing a six-minute explanation of a restored clock. Its inventory and acceptance cases are original examples, not a report of an actual media experiment. The task is delivery of finished audio, rather than generating a voice, editing a video or choosing a production service.
Identify the exact recording being published
Give the asset a title, language, edition and responsible editor. For the museum, edition three corrects an instruction about winding the clock. The old and new recordings can sound similar while giving different instructions, so an unexplained filename is inadequate evidence of which one appears on the website.
Keep the approved source recording recoverable. Record the final public file address separately from the editing project and from a temporary preview link. List every page using the file before replacing it. A correction on the main guide should not leave the older edition in a related article or translated page.
| Inventory item | Fictional entry | Check after publication |
|---|---|---|
| Recording | Clock care, edition three, English. | The audible correction is present. |
| Player destination | The approved public media file. | A visitor can request and play that file. |
| Transcript | Edition three, with relevant sounds identified. | The winding instruction matches the recording. |
| Optional file route | A labelled audio-file link. | The destination and access conditions are clear. |
Build a useful page around the player
Put the recording’s purpose before its controls. A title and concise introduction should explain what the listener will learn, the language and any necessary context. If a duration is shown, obtain it from the finished recording rather than estimating from the script. Update it after editing.
Keep the written explanation available without requiring playback first. Someone using a quiet office, limited connectivity or a different reading method should not have to discover a broken player before finding the answer. Position the transcript route beside the recording, with a label such as “Read the clock-care transcript.”
The WAI transcript guidance describes relevant speech and non-speech information and recommends making the transcript easy to find. For prerecorded audio-only material, text alternatives are a different consideration from live audio. Decide what this particular recording needs rather than treating every media format as identical.
Use supported audio controls deliberately
MDN’s audio reference documents browser controls and source selection. A player may appear even when its file cannot be decoded or retrieved. Text placed inside the audio element is fallback for unsupported elements; it is not a dependable error message for a supported player whose file fails.
Keep a transcript and any ordinary file link outside that dependency. A visitor should still find them if the player displays an error. For the museum, the independent transcript remains part of the article even when the recording is temporarily unavailable.
Choose visitor-controlled playback for an ordinary spoken explanation. Do not make the recording start unexpectedly or hide the pause control to preserve a visual design. Review the actual controls in the browsers you support rather than assuming identical layouts across devices.
Configure the block and loading preference
The native WordPress Audio block supports uploading a file, choosing existing media or supplying a URL. Select the intended asset, save the article and check the public output. Replacement changes need the same review as the original insertion; an uploaded file does not establish a working public journey.
Preload settings express a browser preference, not an enforceable transfer limit. MDN distinguishes none, metadata and auto, with the browser ultimately deciding what to fetch. A setting labelled “none” cannot justify a claim that the entire page makes no media-related requests. Inspect the actual public behavior if loading cost is the concern.
Record who owns delivery when the file is external. A local player pointing to a remotely controlled file still depends on that destination. Do not bypass an access restriction or copy somebody else’s recording because a preview worked previously.
Make the transcript match the finished sound
Review the transcript against the exported recording, not only against the script used to produce it. Editing can remove a warning, rearrange a sentence or introduce an announcement absent from the original script. Pay particular attention to names, quantities, negatives and instructions.
In the fictional museum recording, an audible bell identifies when to stop turning a handle. The transcript needs to communicate that relevant event, not merely reproduce spoken words. Identify speakers where necessary to understand the exchange and use paragraphs or headings that make the text readable.
Give corrections an explicit owner. If the final audio changes its instruction, update the transcript and surrounding article in the same release. A small edition note in the editorial record helps prevent accidental pairing of a new file with old text without turning every paragraph into a version label.
Describe file access without promising a forced download
An optional file route should identify the item being opened, its format and any verified size information that helps the reader decide. A direct audio-file link may open a browser player rather than force a save, particularly across different delivery arrangements. Describe the usable destination honestly.
Keep ordinary file access separate from a button that generates or exports something. If the visitor requires an account, state that before sending them away. Avoid placing a private expiring editor link in a public article.
The link-handoff guide covers the separate choice between ordinary navigation, new tabs and download intent. For this recording, the priority is a correct public asset and a clear alternative, rather than a particular visual button style.
Diagnose the failure you can actually observe
| Symptom | First evidence to collect | Keep available |
|---|---|---|
| No player appears | Compare saved block and published page. | Title and transcript route. |
| Player appears but cannot start | Inspect the exact file request and reported playback failure. | Independent written explanation. |
| Playback starts and stalls | Record device, connection, point of interruption and file response. | A clearly labelled alternative route. |
| Instructions disagree | Compare the audible passage with the transcript edition. | A corrected, clearly identified explanation. |
Change one responsible layer at a time. An absent block, inaccessible file and incompatible recording are different findings. Installing a second player without identifying the failure can add another dependency while leaving the original delivery defect intact.
Review listening, reading and replacement
WAI’s media-player guidance calls for usable controls, including keyboard operation and perceivable states. Native controls are a useful starting point, but they do not certify the whole page. Review the control names, visible focus and ability to move into and out of the player.
- Open the public page anonymously and confirm the correct title, language and recording.
- Start, pause, resume and seek to the corrected passage on supported desktop and phone setups.
- Reach the transcript without activating audio and compare it with the finished recording.
- Check any optional file route and its stated access conditions.
- Exercise a deliberately unavailable test asset in a controlled copy and confirm the written route remains useful.
- Repeat the relevant checks after replacement, including pages that reuse the recording.
Record which combinations were checked and which remain untested. For video rather than audio-only material, use the video publishing guide and the separate timed-caption workflow. Accept this audio page when listening and reading lead to the same maintained information, including when the player cannot help.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN: HTML audio elementChecked Native controls, source handling, preload hints and the limits of unsupported-element fallback text.
Limits: A visible player or successful upload does not establish playback of the actual file across supported devices. - W3C WAI: TranscriptsChecked A useful transcript conveys relevant speech and sounds and is easy to locate beside the recording.
Limits: Prerecorded audio-only and live media have different requirements; a transcript is not a whole-page accessibility certification. - W3C WAI: Accessible media playersChecked Review of keyboard operation, understandable controls and perceivable player states.
Limits: Player choice does not replace testing the surrounding page and the intended user journey. - WordPress: Audio blockChecked Native upload, Media Library, URL and replacement workflows for an Audio block.
Limits: Browser loading preferences remain hints, even when editor descriptions sound absolute; inspect the installed editor and public output.