Accessibility statement

Make the workflow and the finished images easier to use

AppScreenshot.online aims to make its public pages and design workflow understandable and usable. This statement describes practical expectations and reporting paths; it does not claim a completed independent accessibility audit or formal certification.

Two different accessibility questions

There is a difference between using the editor and reading the images it produces. The website needs navigable controls, clear labels, visible focus, and understandable feedback. The finished artwork needs readable text, sufficient contrast, accurate information, and a composition that remains clear at smaller sizes. A well-labeled editor control cannot fix low-contrast text in an export, and a beautiful export does not prove that every editing action is accessible. Review both parts of the workflow according to the people who will use them.

Keyboard and interface use

Use the browser’s normal keyboard navigation to move through links and controls, and look for a visible focus indicator. Complex canvas tasks can require additional inspection because a visual position or selected layer may be difficult to understand without sight. When reporting a barrier, describe the task and the point where navigation or feedback fails. Include whether the issue concerns selecting an element, reading a control label, changing a value, closing a panel, or starting a download. Avoid assuming that all canvas interactions have an equivalent accessible path.

Design exports for real viewing conditions

Store images are frequently seen on small displays and in scaled previews. Keep headline text short, avoid very thin type, and separate foreground text from a busy background. Do not depend on a pale accent color to carry the meaning of a label. A gradient can look readable at one point and lose contrast at another, so check the whole area behind the text. Enlarge an important interface detail instead of surrounding it with a long explanation that becomes too small to read.

Meaning should survive without decoration

Use words and interface evidence to explain the app rather than relying only on color, a decorative arrow, or a device angle. If two options differ, label them clearly instead of showing only two different swatches. Avoid copy that assumes a specific ability or dismisses accessibility needs. When placing exported images on your own website, supply appropriate alternative text in that website’s markup. Text rendered inside an image does not become selectable or screen-reader-readable just because it was editable in this tool.

Language and motion

Translated copy may expand, and right-to-left language can change text alignment and reading order. Inspect the final rendered result with someone who understands the target language, particularly when numbers and Latin app names appear in the same sentence. The exported screenshots are static images; any website motion should remain secondary to understanding and respect reduced-motion preferences. Do not use a moving demonstration as the only way to explain an editing step or make a link understandable.

Report a barrier with enough context to act on it

Email contact@appscreenshot.online with the page or task, your browser, and any relevant assistive technology. Describe the expected behavior and the actual behavior. A concise reproduction is helpful, and you can omit private project images. There is no promised remediation deadline or claim that every known barrier has already been resolved. Feedback can identify where a control, explanation, or alternate path needs improvement. If a problem stops you from protecting your work, download a project backup through any available path before closing the session.

Start with something original.

Pick a free template or open a blank design, then make the story your own.

Explore free templates →