Accessibility Statement

Accessibility is part of how the app is built, not a pass we do at the end. When we add a screen, we check that it can be reached by keyboard, read by a screen reader and used on a small phone before it ships.

We would rather tell you honestly where we fall short than publish a claim we cannot back up. The known gaps are listed below.

We build toward the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA. That is our target, not a certification. We have not completed an independent audit, and we do not claim full or verified conformance. Parts of the app meet the target today; the areas we know do not are in section 4.

• Contrast — a dark, high-contrast palette with body and heading text chosen to stay legible against the surfaces behind it.
• Touch targets — interactive controls are sized to at least 44 by 44 pixels, so buttons and links can be hit reliably on a phone.
• Structure — semantic HTML: real headings in order, real lists, real buttons and links, and form controls with visible, associated labels.
• Keyboard — the interface is operable with a keyboard. Controls are reachable in a logical order and show a visible focus state.
• Screen readers — icon-only and graphical controls carry text alternatives. The logo mark, for example, is a decorative graphic with the letter it represents exposed as screen-reader text, so the brand name is read correctly.
• Reduced motion — the breathwork player respects the operating system "reduce motion" setting: the animated expansion is dropped and the same breathing cue is conveyed without movement.
• Responsive layout — the app reflows down to small mobile widths and supports browser zoom and enlarged text without content being cut off.
• Not color alone — where color carries meaning, such as a status or a completed session, it is paired with text, an icon or a shape so the meaning survives without color.

These are real gaps. We are working on them.

• Video captions — video content will need captions and, where speech carries instruction, a transcript. Captions are part of our requirement for any video we publish, and video added before that is complete will be accompanied by a written description of the movement.
• Charts on Progress — some visualizations on the progress screen show trends graphically. Each one has a written summary next to it with the key numbers, but the charts themselves are not yet fully described for screen-reader users, and the underlying figures are not yet exposed as a data table.
• Payment pages — checkout runs on pages hosted by our payment provider. We do not control their markup or their accessibility, and we cannot fix barriers there directly. If you hit one, tell us and we will raise it with them and help you complete the purchase another way.

The app is built with standard web technologies and is intended to work with current versions of the major browsers on desktop and mobile, together with the screen readers and magnification tools built into those platforms. If your setup is not working, we want to know which browser, operating system and assistive technology you are using — that is usually enough for us to reproduce the problem.

If any part of PHYSIOATHLETX is hard or impossible for you to use, email support@physioathletx.com. Tell us:

• the page or screen where it happened;
• what you were trying to do and what blocked you;
• the browser, device and any assistive technology you were using.

We aim to respond within 5 business days. If a fix will take longer than that, we will tell you when to expect it and, in the meantime, provide the information or carry out the function for you in another accessible way — for example by email — at no extra cost.

Accessibility feedback is handled as a product issue, not a support ticket to close. Reports that show a real barrier go into the build queue.

support@physioathletx.com