A prospective review protocol for small SVG motion handoffs

Scope and status This document proposes a practical review protocol for teams that exchange small animated vector graphics for use in web interfaces. It is a methods note, not a completed study, a dataset, a benchmark or a claim about measured accessibility. The protocol is intended to help an author state what a graphic is meant to communicate, preserve an editable source and describe what has and has not been checked. It can be adapted for an icon, logo, decorative indicator or other small graphic. The examples are hypothetical and do not report actual participants or user outcomes. The document is associated with the SVG Animation project. Artificial intelligence assisted with drafting and editing the text. The project provides a browser-based workflow for SVG source editing, motion presets, optional AI assistance, and SVG, GIF or MP4 export. Its public homepage is animated svg. Consult that site for current features, limits and pricing. Mention of the project is not an independent evaluation or institutional endorsement, and the protocol does not require the project to be used. The author must hold the rights needed to share any artwork, source file or screenshot included in a later application of this protocol. Define the communication task A review begins by identifying the question the movement is expected to answer. For an interface indicator, the question might be whether a state has changed. For a decorative emblem, the goal might be to add visual rhythm without conveying a system status. These are different tasks. A decorative loop should not silently become the only sign of a significant error, and a status cue should not depend entirely on an aesthetic interpretation. Write a short purpose statement and identify whether the graphic is essential to the message or can be removed without losing information. Record the trigger separately from the artwork. An SVG file can contain animation instructions, but the surrounding application determines when the graphic is shown and what events it represents. The review should identify who is responsible for connecting the cue to application state. If the state is only simulated in a design preview, call it a simulation. Do not describe a real-time integration as complete until it has actually been implemented and checked in the receiving environment. Establish a baseline Before comparing motion variants, prepare a static baseline using the same visual elements. Check whether the graphic is recognizable at the intended size, whether it obscures neighboring text, and whether the contrast remains adequate over representative backgrounds. The selection of backgrounds should reflect the planned use rather than a promise to cover every screen. Note which sizes and backgrounds were inspected and which are still open questions. The static baseline also gives reviewers a meaningful alternative. If a moving effect makes a status less clear than the still image, the team can simplify it or retain the static treatment. A baseline is not automatically an accessible fallback: it must communicate the relevant information, and the application must actually provide it in the circumstances for which it is intended. The review record should distinguish a proposed alternative from one already implemented. Describe the candidate motion For each candidate, list the visible starting state, the transition, the resting state and the expected behavior at the loop boundary. The record need not contain every keyframe. It should be specific enough that another person can understand what is being compared. If two alternatives differ only in duration, keep the artwork and placement stable while reviewing them. If several properties change together, identify that limitation rather than attributing a difference in perception to a single parameter. Record whether motion is triggered once, repeated, or controlled by external state. Consider what happens when a scene changes midway through a transition or when a component is removed and reinserted. These questions cannot be settled merely by replaying an isolated animation. They belong to the integration plan and should be checked in the actual application when an implementation is available. A note that an interruption test remains unperformed is more useful than an unsupported statement that the animation is robust. Consider reduced motion and readable alternatives A responsible handoff describes what should happen when movement is reduced or unavailable. Depending on the purpose, a static icon, direct text label or shorter transition may be a suitable alternative. When a graphic communicates an important state, confirm that reducing the motion does not remove the only way to perceive that state. For a decorative element, disabling it entirely may be a reasonable choice. The specific decision should be documented alongside the reason. Reviewers should not infer conformance with a standard from the presence of a fallback alone. Record the relevant settings, browsers, devices and assistive technologies only if they were actually tested. If a review relies on visual inspection, describe it as visual inspection. A later formal accessibility assessment may use this protocol as a starting record, but it requires its own criteria, evidence and appropriate expertise. Track source, previews and exports Keep the editable source distinct from review copies. A small animated GIF can be convenient in a message, but it may omit information needed for later changes. An MP4 may be useful for a presentation, while an SVG may be more appropriate for a web implementation. These formats differ in editing, transparency, scaling and playback behavior. The protocol does not assume that one export format is always superior. Assign a clear version label to each file and identify which source produced each preview. Record dimensions, export settings and the destination application when those details are available. Before sharing, open the actual exported file in the environment for which it is intended. A button that offers an export is not evidence that every receiver can use the resulting file, and an attractive preview is not proof that an application will respect a reduced-motion setting. Preserve rights and private information Use material that the author is permitted to edit and distribute. A demonstration can use invented shapes and neutral labels instead of private client artwork or a real user record. If a screenshot includes personal information, determine whether it is necessary for the review and remove or protect it before sharing. Document any external font, image or code dependency whose rights or availability could affect a handoff. This text may be shared under the license stated in its repository record. That license applies to the original text in this document only. It does not grant rights to a third-party product, its source code, logos, exported artwork or separately linked materials. The presence of a website link is a reference to the project and should not be interpreted as permission to reuse all content found there. Use a concise review card The following fields provide a minimal starting point: graphic name and version; intended purpose; trigger and expected resting state; destination and approximate display size; static or reduced-motion alternative; source filename; preview and export filenames; tests actually performed; known limitations; and a contact or owner for the next decision. An empty field can be marked unknown or not yet tested. Do not fill it with an invented result simply to make the card appear complete. Comments should describe observations in context. For example, a reviewer might say that a label was difficult to read at a particular window width while the overlay crossed it. That observation is more useful than a vague instruction to improve the design. If the issue is hypothetical, label it as hypothetical. If the person testing used only a preview image, do not represent the observation as a production-browser test. Decision and revision At the end of a review, record whether the candidate was accepted for a defined context, needs revision, or remains undecided. An approval for one setting does not automatically extend to every device or publication. Keep the previous editable version when feasible, describe what changed, and revisit the decision if the surrounding layout, playback environment or content changes substantially. This protocol is deliberately prospective. It offers a structure for a future review rather than a claim that one has occurred. Its value is in making assumptions visible: the task of the animation, the conditions of inspection, the location of the source and the boundaries of the evidence. A team can shorten or expand the card to fit its work, provided it continues to separate what was proposed, what was actually observed and what still requires testing.