Accessibility

Our Commitment

We are committed to making Fomatic usable by as many people as possible, including people who navigate by keyboard, use a screen reader or other assistive technology, enlarge text, or rely on sufficient color contrast.

We treat accessibility as part of building the product rather than as a review at the end. Automated checks run against every change, and what they cover is described below in plain terms so you can judge it for yourself.

Standard Applied

We measure Fomatic against the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. That is the level most commonly referenced by procurement teams, and the level referenced by public-sector rules in the United States and by EN 301 549 in Europe.

Conformance Status

Fomatic is partially conformant with WCAG 2.2 Level AA. Partially conformant means most of the product meets the standard, and some parts have not yet been fully verified.

We say partially conformant deliberately. Automated tools reach roughly a third of the WCAG success criteria. Everything our tools can check currently passes across the organizer application, the sponsor portal, the guest portal, the platform console, and the public site. The rest depends on review we have not finished, and we would rather tell you that than claim more than we have measured.

Known Limitations

These are the areas we know are not yet fully verified, as of September 18, 2026:

• Screen reader review. Our automated checks confirm that controls carry names, roles, and states. We have not yet completed a structured review with JAWS, NVDA, and VoiceOver across the main workflows, so announcement wording may be uneven in places.
• The mobile app. The Fomatic guest app for iOS and Android is newer than the web product. It carries a narrower check — that every control it offers has something to announce — but not the full set the web product gets. The web guest portal does.
• Customer-supplied content. Event names, activity descriptions, uploaded images, and files come from organizers. We cannot guarantee the accessibility of content we did not write, and we do not require alternative text on uploads.

If you hit a barrier that is not listed here, we want to know. It means our testing missed it.

How We Test

This is the part procurement reviewers usually ask about, so it is worth being specific.

• Every change is linted for accessibility. The recommended eslint-plugin-jsx-a11y rule set runs before any change can be committed. It catches the structural mistakes: controls with no keyboard path, form labels tied to nothing, invalid ARIA.
• Every screen is scanned with axe. An automated sweep loads each significant route of the product in a real browser, in both light and dark themes, and checks it against WCAG 2.0, 2.1, and 2.2 A and AA rules, including target size. The sweep currently reports zero violations.
• Shared components are scanned in their states. A route only shows a control at rest. Unit tests scan the shared checkboxes, labels, buttons, and badges in their checked, invalid, and disabled states as well.
• Keyboard focus is walked automatically. A test tabs through the main screens and asserts that the focused control is never scrolled out of view or hidden behind a fixed header.
• Zoom and spacing are tested, not assumed. Automated tests load the main screens at the width 400% zoom produces, at double the text size, and with wider line and letter spacing applied, and check that nothing is cut off or pushed off screen.
• Dialogs are tested for keyboard traps. A test opens a dialog, tabs twenty-five times to confirm focus cannot escape it, then presses Escape and confirms focus returns to the control that opened it.
• Color contrast is computed, not eyeballed. Every text color in the product is checked by calculation against each background it can appear on, in both themes, against the 4.5:1 minimum. That includes the gradients behind profile initials, which automated tools report as unmeasurable and skip — checking them by hand is how we found and fixed them.

Tested Environments

Our automated checks run in current Chromium at a 1440 by 900 desktop viewport, in both light and dark themes. Fomatic is built with standard web technologies — HTML, CSS, JavaScript, and ARIA — and is designed to work in current versions of Chrome, Edge, Safari, and Firefox on desktop and mobile. JavaScript is required.

Measures We Take

• Accessibility checks block a change from being committed, rather than being a separate review step that can be skipped.
• Our internal design documentation records the accessibility contract for shared components, so the next person building a screen inherits it instead of rediscovering it.
• Where a mistake can be prevented by the type system, it is. A checkbox without an accessible name, for example, fails to compile.
• Every interaction that can be performed by dragging can also be performed without dragging.

Feedback

If you have trouble using any part of Fomatic, or you need information from it in a different format, contact us at accessibility@fomatic.ai. Please tell us the page or screen, what you were trying to do, and the browser and assistive technology you were using. We aim to respond within five business days.

This statement was prepared by Fomatic, Inc. on September 18, 2026, based on an internal self-evaluation using the automated and manual review described above. It has not been independently audited by a third party. We review it whenever the product changes materially.