WCAG in Practice: What We Automate and What We Check by Hand

Text scaling up to 200 percent

Flowo honors the system text size between 85% and 200%. The app root reads the platform text scaler and clamps it to that range before any screen is built. The upper bound matches WCAG 1.4.4 Resize Text, which asks that text can grow to 200% without loss of content or function.

Layouts change at set thresholds so that large text has somewhere to go:

• Tab bar labels are hidden when the scale exceeds 1.4 or the bar is narrower than 360 points. The icons keep their accessibility labels.
• Onboarding keeps its action buttons pinned to the bottom below a scale of 1.5. From 1.5 upward the buttons join the scrolling content.
• Sheets wrapped in our sheet cap widget stop 12 points below the status bar, so a sheet that grows with large text cannot slide under the clock.

These rules have tests. One renders the tab bar at a scale of 2.0 and asserts that the visual label is gone while the semantic label "Thoughts" is still found. Another opens the consent screen at 2.0 and scrolls until the save button is visible.

The clamp is also a limit. iOS offers accessibility sizes above 200%, and Flowo stops growing at 200%.

Reduced motion and reduced transparency

Flowo applies the system reduced motion setting once, at the root of the app, so every screen below reads the same value. Individual widgets then check it. The press animation on buttons stops scaling, toasts appear in place without sliding, the navigation bar shows and hides without its spring, and the completion confetti is never built.

Our websites handle the same preference in CSS:

• bbmmtech.com turns off smooth scrolling and removes the press transform on buttons.
• flowoapp.com and textpack.app set every animation and transition to 0.01 ms under prefers-reduced-motion.
• The hero film on flowoapp.com stays on its poster frame when reduced motion is on. When it does play, it pauses off screen and in a hidden tab, and it has a pause button, which is what WCAG 2.2.2 Pause, Stop, Hide requires of moving content.

Transparency has its own switch. Flowo's Appearance screen has a Reduce Transparency toggle that makes the navigation bar opaque and disables its blur, and a widget test asserts both. On bbmmtech.com and flowoapp.com the prefers-reduced-transparency query replaces translucent surfaces with a solid fill.

The app's settings model also stores a reduce motion flag and a high contrast flag, and the theme reads both. The Appearance screen does not expose them. For now the system settings are the way to turn those behaviors on.

Focus styles and keyboard order on the sites

All three of our websites draw a visible outline on keyboard focus through one global :focus-visible rule each. The values and their measured contrast against the page are these:

• bbmmtech.com: 2 px solid #0066CC, 3 px offset. 5.57:1 on white.
• flowoapp.com: 2 px solid #004E72, 2 px offset. 8.07:1 on the #F2F2F7 page.
• textpack.app: 3 px solid accent, 3 px offset. #B6421A measures 5.18:1 in light and #FF8A65 measures 7.97:1 in dark.

Each outline clears the 3:1 that WCAG 1.4.11 asks of a focus indicator.

bbmmtech.com and flowoapp.com put a "Skip to content" link first in the tab order. It stays off screen until it receives focus, and its target is the main content container.

The analytics consent dialog on bbmmtech.com moves focus to its first button when it opens. When it is reopened from the cookie preferences control, focus returns to that control after the choice. Escape closes it only when a choice is already stored, so the first decision cannot be dismissed by accident.

Semantics, labels and targets

Every field in the bbmmtech.com contact form has a visible label tied to its input by id. The inputs declare autocomplete values for name, organization and email. A failed submission renders a message with role="alert", so a screen reader announces it without a focus change.

Images are split by purpose. Product icons that sit beside a product name have an empty alt attribute. Screenshots carry a description of what they show, for example "Flowo showing a planned day".

In the app, a subtask's completion control is tested as a checkbox. The test requires a semantic label equal to the task title, a checked state, a tap action and a size of 48 by 48 logical pixels.

Two smaller rules protect people who use assistive technology. When the navigation bar is hidden, it is removed from the semantics tree and stops receiving touches, so a screen reader cannot land on an invisible control. A toast that carries an action does not start its dismissal timer when the system reports accessible navigation. That follows WCAG 2.2.1 Timing Adjustable.

What runs automatically

The automated checks for the Flowo app run inside flutter test, which our CI requires together with formatting and static analysis. The tests that bear on WCAG are these:

• Contrast assertions on color roles, form inks and onboarding text, each at the 4.5:1 or 3:1 threshold that applies.
• Navigation tests at 200% text, at a 320 pixel width, in right-to-left and with reduced motion.
• A localization test that checks seven locales and the text direction of each.
• Semantics tests for specific controls, such as the subtask checkbox.

For flowoapp.com, the deploy workflow runs lint, unit tests and the build. The repository also holds a Lighthouse CI configuration that sets a floor of 0.95 for the accessibility category, taken as the median of three desktop runs. That configuration is not called by the deploy workflow today, so it does not gate a release.

What we check by hand and what is still open

Screen reader traversal is manual work for us. Our quality checklist has an item that every flow must be completable with VoiceOver and TalkBack. A quality run recorded in August 2026 marks whole-app traversal as unverified, and the checklist item is still unchecked.

Visual checks are manual too. Our process for palette changes calls for simulator captures of the main screens in light and dark, on iPhone and iPad.

These are the gaps we know about:

• Flowo's tests do not run Flutter's built-in accessibility guideline matchers across screens. Tap target size and labels are asserted control by control.
• The corporate site has no automated accessibility test. Its test suite covers analytics consent and publishing logic.

We do not publish a formal WCAG conformance statement for any of our products today.