Guides

Rendering and visual verification

Specify the conditions before judging the result.

A rendering contract fixes the context

A visual output depends on more than scene properties. Viewport, resolution, device scale, locale, fonts, asset versions, color space, time, camera and user preferences can all change the rendered result. Record the conditions that matter to your comparison.

Keep implementation hints distinct from requirements. A desired visual arrangement may be achieved with different layout engines. Conversely, an exact output size or a specific semantic relationship can be a hard requirement regardless of implementation.

Tolerances belong to assertions

An acceptable spacing deviation is different from an acceptable timing deviation. Describe a validation target, metric and tolerance in the context of the aspect being evaluated. Avoid a single unexplained percentage that appears to summarize unrelated qualities.

Use exact assertions for discrete conditions such as a selected state or the existence of an accessible name. Use meaningful units for continuous tolerances. A requirement marked critical should not be hidden by averaging it with unrelated passing checks.

Capture more than pixels

For a static composition, capture an image under declared conditions. For interaction, record state changes and keyboard behavior. For motion, compare time samples and interruption results. For semantics, inspect the target accessibility representation and test its operation.

Preserve the source document version, adapter version, resolved resources and evidence locations with each report. Report unavailable evidence as unverified, rather than passed.

Progressive implementation

An adapter can begin with a small, well-tested set of features. A truthful capability statement and precise unsupported-feature diagnostics are more useful than implying every profile renders. The browser preview follows this principle: it demonstrates a subset and exposes the complete JSON for inspection.