Accessibility statement

1. Our goal

We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA on this website, and to follow Apple’s accessibility guidance in the app by building on standard system controls rather than reinventing them.

That is a goal we work toward, not a certification. This site and app have not been independently audited or certified by a third party, and we do not claim full conformance. Where we fall short, we would rather say so and fix it than publish a conformance badge.

2. In the iPhone app

HabitStakes is built with SwiftUI using standard system controls, which means it inherits iOS accessibility behaviour rather than working around it:

• VoiceOver can reach the app’s controls, which use standard buttons, lists, toggles, navigation, and alerts with system-provided semantics.
• Dynamic Type is supported through system text styles, so text scales when you increase text size in iOS.
• Bold Text, Increase Contrast, Reduce Transparency, and Reduce Motion are honoured by the system controls the app is built from.
• Colour is not the only signal. Protected, forfeited, and unresolved days carry text labels and distinct symbols as well as colour.
• Destructive actions are confirmed. Ending a commitment and deleting local data both require an explicit confirmation that states what will and will not be removed.
• Plain language. Status messages describe what happened and what to do next, rather than showing error codes.
• Portrait, one-handed reach. The app runs in portrait on iPhone with primary actions placed within thumb reach.
• No time pressure inside a screen. Nothing in the interface expires while you read it. Commitment days end on the calendar, which is the point of the app, not an interface timer.

3. On this website

• Semantic HTML throughout: real headings in order, landmarks, lists, tables with header cells and captions, and descriptive link text.
• Keyboard accessible. Every interactive element is reachable and operable with a keyboard, there are no keyboard traps, and a “Skip to main content” link is the first focusable item on every page.
• Visible focus. A high-contrast focus ring is drawn on any element you reach by keyboard.
• No JavaScript at all. Nothing on this site depends on scripting, so nothing breaks when scripts are blocked. Expandable sections use the native details element.
• Contrast. Text and interface colours were chosen against WCAG contrast ratios, with a target of at least 4.5:1 for body text and 3:1 for large text and interface boundaries.
• Reduced motion. The only motion is a short entrance animation and small hover transitions, and all of it is disabled when your system requests reduced motion. There is nothing that flashes, autoplays, scrolls on its own, or moves for more than a moment.
• Reflow and zoom. Layouts are fluid, text is set in relative units, and pages remain usable at 400% zoom and on narrow screens without horizontal scrolling, apart from wide data tables which scroll horizontally inside their own container.
• Images. Screenshots have descriptive alternative text; purely decorative images are hidden from assistive technology.
• No interruptions. No pop-ups, cookie banners, interstitials, auto-refresh, or time limits.
• Readable when printed or saved: the legal pages have a print stylesheet that drops navigation and decoration.

4. Known limitations

Being specific is more useful than a blanket claim:

• Screenshots are images of the app interface. Their alternative text summarizes what the screen shows, but it cannot convey every number and label in the picture.
• The legal pages are long. There is an “On this page” navigation at the top of each one, but reading them in full with a screen reader still takes time.
• Wide tables scroll horizontally on small screens.
• Neither the app nor this site has completed a formal, independent accessibility audit, and testing of the app with every assistive technology and iOS setting combination is not complete.
• The site and app are currently available only in English.
• Parts of the experience are controlled by iOS — notification presentation, widget rendering, Live Activity layout, and the Apple Health permission sheet — and their accessibility behaviour is Apple’s.

5. How this was assessed

This statement is based on our own review: building on standard system and native platform components, checking colour contrast ratios during design, keyboard-only navigation of every page on this site, checking the site with scripting disabled and with reduced-motion preferences set, and validating the page structure. It was not evaluated by an external auditor, and it is not a formal conformance report such as a VPAT or an accessibility conformance report.

6. Tell us about a barrier

If any part of HabitStakes or this website is difficult or impossible for you to use, please email support@scalingadventures.com and tell us:

• the page or screen involved;
• what you were trying to do;
• the assistive technology and settings you use, for example VoiceOver with a particular text size, or a specific browser and screen reader; and
• what happened instead.

We treat accessibility reports as real bugs and prioritize them accordingly. We read every message and respond as promptly as we reasonably can, but we cannot promise a guaranteed response time or a fixed remediation deadline. If you need information from this site in a different format, ask and we will try to provide it.