Last updated: 7 September 2026

Accessibility Statement

The short version: we want everyone to be able to read this site and use our apps. We aim to meet WCAG 2.2 level AA, we have built the site with plain semantic HTML and keyboard reachable controls, and we know about some gaps that we are still working on. If something blocks you, tell us and we will fix it.

• 1. Our commitment
• 2. The standard we aim for
• 3. Measures we take
• 4. Known limitations
• 5. Accessibility in the Apex Health app
• 6. Tell us about a problem
• 7. How this statement was prepared
• 8. Keeping this statement current

1. Our commitment

Truestep Solutions builds software for a living, and we think an interface that excludes people is a defect rather than a matter of taste. We aim to make truestepsolutions.in and the products we publish usable by as many people as possible, including people who use a screen reader, navigate by keyboard alone, magnify the screen, need larger text or stronger contrast, or prefer reduced motion.

Accessibility is not a task we finish once. We check it as part of building and reviewing pages, and we treat a reported barrier as a bug with a real owner and a real fix.

2. The standard we aim for

We target the Web Content Accessibility Guidelines version 2.2, at conformance level AA, as published by the World Wide Web Consortium. We describe the site as partially conformant with WCAG 2.2 level AA, which means that most of the site meets the standard, that we are aware of specific areas that do not yet meet it, and that those areas are listed openly below rather than left unsaid.

3. Measures we take

• Semantic HTML first. Pages are built from real headings, lists, paragraphs, tables, landmarks and links, in a sensible reading order, so that assistive technology can announce structure correctly. Headings follow a logical hierarchy and are not chosen for their size.
• Keyboard reachable controls. Every interactive control, including navigation, expandable sections and the cookie preferences control, can be reached and operated with a keyboard alone, in an order that matches the visual layout. We avoid keyboard traps and we do not rely on hover to reveal anything essential.
• Visible focus. The focused element keeps a clearly visible focus indicator, so it is always obvious where you are on the page.
• Text contrast. Body text, headings and link text are checked against the WCAG contrast thresholds for normal and large text, and we do not use colour on its own to carry meaning.
• Reduced motion respected. Animation and parallax effects are decorative. When your system asks for reduced motion, we honour that preference and the content stays fully usable without the movement.
• Native disclosure elements. Expandable content, such as frequently asked questions, uses the browser's own details and summary elements rather than a custom widget, so the keyboard behaviour, the expanded state and the screen reader announcements are the ones the browser already gets right.
• Text that scales. Layouts use relative units and reflow rather than break when text is enlarged or the browser is zoomed.
• Meaningful link text and alternatives. Links describe where they go rather than saying "click here", images that carry meaning have text alternatives, and images that are purely decorative are hidden from assistive technology.
• Testing as we build. We check pages with keyboard only navigation, with browser zoom, with a screen reader, and with automated accessibility checks, before they are published.

4. Known limitations

We would rather be honest about the gaps than claim a clean sheet. We are aware of the following, and we are working on them.

• Wide data tables scroll horizontally. Some comparison and specification tables carry more columns than a small screen can show, so on a narrow viewport they sit in a horizontally scrolling container. The scrolling region is keyboard reachable, but reading a wide table on a phone is still harder than it should be. We are working on a layout that reflows these tables into stacked rows.
• Third party embedded content. Content served by other providers, including embedded media, external documentation and the App Store and TestFlight pages we link to, is outside our control. We cannot fix accessibility problems inside somebody else's product. Where an embed causes a barrier, we will look for a more accessible alternative or provide the same information directly on our own page.
• No independent audit yet. This site has not been audited by an independent third party or tested with a formal panel of users with disabilities. Our checks are our own, and self testing misses things that real users find. Arranging an external review is on our plan.
• Older content. A few older pages and downloadable documents were written before our current checks were in place and may not fully meet the standard. We are reviewing them, and we will provide the content in an accessible form on request in the meantime.

5. Accessibility in the Apex Health app

Apex Health: Sleep & Recovery is built with Apple's own interface frameworks so that it inherits the accessibility features people already rely on in iOS and watchOS. The app supports Dynamic Type, so text follows the size you have set for the system, including the larger accessibility sizes. Screens, scores, charts and controls are labelled for VoiceOver, so they can be read out and operated without sight of the display. The app also respects the system Increase Contrast setting, and it follows the system reduce motion preference for its animations.

If you find a screen in the app that a screen reader announces poorly, that clips at a large text size, or that is hard to read with Increase Contrast switched on, please report it in the same way as a website problem and we will fix it in a coming release.

6. Tell us about a problem

If any part of this site or of our apps is difficult or impossible for you to use, we want to hear about it, and your report is genuinely useful to us. Write to hello@truestepsolutions.in with the subject line "Accessibility". Please include:

• The web address of the page, or the name of the screen in the app.
• What you were trying to do and what happened instead.
• The browser, operating system and any assistive technology you were using, if you know them, including the versions.
• A screenshot or a short recording, if that is easier than describing it.

We aim to acknowledge every accessibility report within two working days, and to give you a plan and a timeline for a fix within ten working days. Where a fix is quick, we usually make it much sooner. Where the barrier sits inside third party content, we will tell you so honestly and offer another way to get the same information. If you need something on this site in a different format, ask us and we will provide it.

7. How this statement was prepared

This statement was prepared on 7 September 2026, and it describes the state of truestepsolutions.in on that date. It is a self assessment carried out by the Truestep Solutions team. It has not been reviewed or verified by an independent third party, and it is not a certification of conformance. Our assessment combined a manual review of pages against the WCAG 2.2 level AA success criteria, keyboard only navigation testing, screen reader spot checks, browser zoom and text scaling checks, and automated accessibility tooling.

8. Keeping this statement current

We review this statement when we make a significant change to the site, and at least once a year, and we update the date at the top when we do. As we close the limitations listed above, we will remove them from the list rather than leaving them there, and if we find new ones we will add them.