Accessibility Statement

Last updated: July 10, 2026

1. Our commitment

STYL ("we," "us," "our") is committed to making STYL — the iPhone app, the Mac app, and this website — usable by the widest possible range of people, including people who use assistive technology such as VoiceOver, Switch Control, Voice Control, and larger Dynamic Type text sizes. Accessibility is an ongoing effort, not a one-time checkbox: as STYL adds features (including visual, image-heavy surfaces like the Coverage Map and photo-based closet grid), we evaluate and remediate their accessibility alongside the rest of the release, not after the fact.

2. Standard we target

We are guided by the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, moving toward WCAG 2.2 Level AA, as the technical standard for both this marketing website and, where WCAG's principles apply to native software, the STYL iOS and Mac apps. On iOS and macOS we additionally follow Apple's Human Interface Guidelines for Accessibility and build on Apple's built-in assistive technologies (VoiceOver, Dynamic Type, Reduce Motion, Voice Control, Switch Control) rather than replacing them with custom equivalents, so STYL benefits from platform-level accessibility improvements automatically.

We reference WCAG and Apple's guidelines as the standard we are working toward. This statement does not, by itself, represent a certification of full conformance.

3. Current conformance status

This status has not yet been confirmed by a formal, independent accessibility audit (e.g., a VoiceOver walkthrough of every screen by a screen-reader user, an automated + manual WCAG audit of the website). We plan to commission one, and will update this statement with its findings.

4. What STYL already does today

These are assistive-technology accommodations already built into the shipping app, not aspirational claims:

• VoiceOver — interactive elements across the app (buttons, tiles, navigation links, stat cards) carry explicit accessibilityLabels that speak a complete, natural- language description rather than a raw icon name or a bare number, and purely decorative glyphs (ghost monograms, background shapes, redundant icon glyphs) are marked accessibilityHidden so VoiceOver doesn't announce visual noise. Composite cards use accessibilityElement(children: .combine) so a screen-reader user hears one coherent sentence per card instead of a scattered sequence of fragments.
• Dynamic Type — text uses the system's scalable type system with lineLimit/minimumScaleFactor fallbacks so labels degrade gracefully rather than clipping at larger accessibility text sizes, instead of hard-coded fixed-size text that ignores the user's preferred reading size.
• Reduce Motion — STYL reads accessibilityReduceMotion throughout the app and swaps animated entrances, breathing/pulsing effects, and motion-driven state changes for an instant, static equivalent when the system setting is on — nothing depends on animation to convey information that isn't also stated in text or a label.
• Custom interactive controls get spoken affordances — for example, the Coverage Map's axis-re-slicing control exposes accessibilityAdjustableAction so it can be operated by swiping up/down with VoiceOver, not only by a visual gesture.
• Standard platform controls — STYL builds on native SwiftUI components (buttons, navigation links, sheets, lists) wherever possible, which inherit VoiceOver, Dynamic Type, Voice Control, and Switch Control support from the platform rather than reimplementing it.

5. Known limitations (being honest about what's not there yet)

We are aware of the following gaps. None of these mean the app is unusable with assistive technology, but they fall short of full WCAG 2.1 AA conformance and are being worked on:

• Some custom tap targets are smaller than the recommended 44×44pt minimum — a few compact icon-only controls (for example, small navigation "grip" buttons on data-dense screens like the Coverage Map) render and hit-test below Apple's and WCAG 2.5.5/2.5.8 target- size guidance, which is harder to hit accurately for users with motor impairments.
• Color is sometimes the primary signal on data-dense visual surfaces — the Coverage Map's gap lattice communicates "healthy vs. thin vs. gap" partly through an accent-color vs. muted-color distinction on 3D-styled tiles; while a text legend and VoiceOver labels exist, we have not yet independently contrast-audited every state combination against WCAG 1.4.11 (non-text contrast) and 1.4.1 (use of color).
• No independent color-contrast audit of the full palette yet — text/background contrast ratios (WCAG 1.4.3) have not been verified pair-by-pair across every screen, in both light and dark appearance, especially "muted" and "faint" secondary-text tones used for captions.
• Photo-heavy surfaces rely on AI-generated text, not human-authored alt text — the closet grid and outfit surfaces are inherently visual (a photo of a garment); category/color/ material tags generated by our AI tagger are surfaced to VoiceOver as the best available description, but they are not a substitute for a purpose-written accessible description and may occasionally be inaccurate, consistent with Section 7 of our Terms of Service.
• Complex custom visualizations partially, not fully, translate to VoiceOver — 3D- styled data surfaces like the Coverage Map's gap lattice and axis dial are built as custom SwiftUI graphics; we've prioritized giving VoiceOver a spoken summary of the data (counts, state, legend) rather than a cell-by-cell rotor-navigable table, which is a simplification, not full parity with the sighted visual experience.
• This marketing website has not yet had an automated WCAG scan (e.g., axe, Lighthouse accessibility audit, or a manual keyboard-navigation pass) run against every page.
• Keyboard-only and Switch Control navigation on the website have not been separately verified beyond relying on semantic HTML and standard focus outlines.

An internal, screen-by-screen engineering audit checklist (including specific tap-target sizes measured in the current codebase) is the source of truth for the remediation backlog behind this section.

6. Assistive technology we support

7. Remediation plan and timeline

We treat the gaps in Section 5 as an active backlog, not a static disclosure. Our internal engineering audit checklist (dated 2026-07-09, covering the account, coverage-map, and related surfaces referenced above) is the working document that turns each known limitation into a specific, trackable fix.

We commit to:

• Reviewing and re-publishing this statement at least every six months, or sooner after any major redesign of a core surface (e.g., the Coverage Map, the closet grid, onboarding).
• Prioritizing fixes for issues that fully block a task with assistive technology (e.g., an unreachable control) ahead of issues that make a task harder but not impossible.
• Publishing target dates here — for closing the tap-target and contrast gaps identified in Section 5, and for a first independent/external accessibility audit of the shipping iOS app — once they are set. We have deliberately not published dates we cannot yet stand behind.

8. Feedback and contact

If you use assistive technology and run into a barrier anywhere in STYL — the iPhone app, the Mac app, or this website — we want to hear about it. Please tell us:

• the assistive technology you were using (e.g., VoiceOver, a specific Dynamic Type size, Switch Control);
• the screen or feature where you ran into the problem; and
• what you expected to happen versus what actually happened.

Contact us at support@styl.fit, or through the in-app Help & feedback composer (Account → Settings → Help & feedback). We aim to acknowledge accessibility feedback within 5 business days and will let you know what we plan to do about it.

If you are not satisfied with our response, you may also have the right to file a complaint with the relevant regulator in your jurisdiction (for example, in the United States, the Department of Justice's ADA complaint process; in the EU/UK, your national accessibility or consumer-protection authority).

9. Third-party and platform content

Some content in STYL depends on components outside our direct control — for example, Apple's own system UI (share sheets, the App Store subscription-management screen, the system camera/ photo picker), and content our AI providers (Section 4) generate as tags or suggestions. We hold ourselves to the same accessibility standard for our own UI wrapping these components, but cannot guarantee the accessibility of platform system UI itself, which is governed by Apple's own accessibility commitments.

10. Related documents

This statement works alongside our Privacy Policy and Terms of Service, which describe AI Outputs (including this app's tag- and description-generation, Section 7 of the Terms) as algorithmic and not guaranteed to be perfectly accurate — a limitation that also affects the accuracy of AI-derived text used as a substitute for alt text (Section 5, above).