Accessibility statement

What is in place

The workspace is built to be used from the keyboard. Ctrl+K (⌘K on a Mac) opens a command menu that runs an action by name, “?” lists every shortcut, and a selected control moves with the arrow keys rather than only by dragging.

Dialogs keep focus inside them, close with Escape and hand focus back to where you were; menus move with the arrow keys. Progress and replies are announced to screen readers as they arrive.

Every public page opens with a link that skips to its content, and its text and buttons meet the 4.5:1 contrast the guidelines ask for, in the light theme and the dark. The light and dark themes follow your system, and motion is reduced when your system asks for it.

Every report Forma writes is checked as DevExpress’s own designer checks it: text too small to read, contrast too low, and pictures with no description are listed in the REPX view.

What is known to fall short

The mockup and the Preview draw a printed page as boxes placed where the report puts them, so a screen reader meets them in layout order rather than reading order. The Spec view describes the same report as structured text.

Retyping a control on the Preview needs a double-click, and its right-click menu needs a pointer; the command menu reaches most of the same actions.

Neither the public pages nor the workspace has yet been tested with a screen reader from end to end, or audited by anyone outside the project.

How it was checked

By the maintainer, with the keyboard and the browser’s own accessibility tools, on the date at the top of this page.

Tell us

If something on Forma is hard or impossible to use, write through the contact page or open an issue on GitHub, and say what you were trying to do and with what browser or assistive technology. You will have an answer within a few days, and a fix or a way round it where one can be made.