Browser release evidence
Keep an enhancement rollout log
A reusable evidence log for introducing a browser feature in stages while keeping behavior, accessibility, fallback and rollback checks separate.
A browser exposing an API answers one question: is that entry point present here? Releasing a feature asks several more. Does the actual interaction work, can people use it with the inputs they need, does the simpler path survive, and can you withdraw the enhancement cleanly?
Keep those answers in separate rows. This rollout log turns a support decision into a record of what has actually been checked at each stage. It is an editorial worksheet, not an automated browser test or an accessibility certification.
Start with an exact change and a working base
Imagine an ordinary help page containing keyboard-shortcut instructions. A fictional change offers the same instructions in a modal dialog while retaining the help-page link. The user task is finding and reading the instructions; the modal presentation is the enhancement.
Identify the release version, the page or component, the exact API and the way the enhancement can be disabled. State the expected base behavior before testing. If the enhancement is withdrawn, the help link should still reach readable instructions without needing its JavaScript.
For native dialogs, MDN documents that showModal() opens a modal in the top layer and makes the rest of its containing document inert. That browser mechanism still leaves the content, naming and interaction choices to the implementation.
Sources: MDN: HTMLDialogElement.showModal()
Keep four evidence rows separate
Presence: record the exact gate being checked. For this example, typeof document.createElement('dialog').showModal === 'function' checks the modal-opening method. It says nothing about whether this particular help control was connected correctly.
Behavior: perform the actual task. Open the help, read the intended content, close it, and repeat the action. Record the version and conditions, then the expected and observed result. A passed presence check cannot fill in this row.
Accessibility: record keyboard navigation, the dialog's accessible name, focus on opening and after closing, and any assistive technology actually used. W3C's modal-dialog pattern describes contained Tab navigation, Escape dismissal and deliberate focus handling. Use it to choose checks; a few checks do not establish whole-site conformance.
Fallback: deliberately disable the enhancement in a test setup, then use the ordinary help link. Also check the intended base path with JavaScript disabled. Record how the fallback was reached so another reviewer can reproduce that state.
Sources: W3C WAI: Modal dialog pattern
Define stages around evidence
Stage one can be a local or private preview. Complete the chosen checks in explicitly listed environments, including browser and operating-system versions, input method and relevant settings. Mark an untested environment as untested rather than inheriting a pass from a compatibility table.
Stage two, where the project supports it, can expose the enhancement to a limited production group with a tested withdrawal path. Google SRE's canary guidance requires a limited population, an evaluation process and release decisions connected to that evaluation. A preview check alone is not a production canary.
Before wider exposure, review the evidence for the changed version and remaining gaps. Google also warns that a handful of requests may not provide representative canary evidence. On a low-traffic site, do not interpret silence or zero recorded errors as proof that every interaction works. Keep targeted checks and coverage gaps visible.
Sources: Google SRE: Canarying Releases
Copy the rollout log
Release record: version, component, user task, enhancement, base path and current exposure stage. Decision rule: what evidence permits the next stage, what blocks it, and who can withdraw the enhancement?
Check record: environment, input method, settings, evidence category, exact action, expected result, observed result, evidence location and status. Use pass, fail, not run or inconclusive. A status needs the observation that supports it.
Withdrawal record: how the enhancement is disabled, whether that action was exercised, and what confirms the base task still works afterward. Open gaps: list the uncovered environments or interactions and the decision they prevent.
Stage decision: hold, expand within a named boundary, or withdraw. Record the reason, the version it applies to, the remaining uncertainty and the next review trigger. When the implementation changes, identify which old evidence needs rerunning.
Read an invented held release
In a fictional preview record for version H1, the modal method is present and opening the help works. The keyboard check records that closing leaves focus in an unexpected place. The base help page works with the enhancement disabled. A planned screen-reader combination has not been run.
The decision is hold. Two passing rows do not cancel the failed interaction, and the unrun check stays unrun. The next action is to repair focus handling and repeat the affected checks for H2, including withdrawal. None of these invented entries is evidence about a real browser.
If the team later expands exposure, its record should name the covered stage and the evidence used. Avoid a single unexplained label such as supported. Someone investigating a later regression needs to know which version, task and conditions earned the earlier decision.
Keep the log beside the implementation
Use the Browser Feature Explorer to find the exact feature entry and its primary references. Read browser readiness when support evidence is unclear, and plan the fallback before a rollout depends on it.
Save only the environment and evidence details needed to explain the release. The worksheet can use role labels and local evidence filenames; it does not require account details, participant names or personal browsing history. Keep the resulting log in your own project files.