Accessibility
Nesteia should be usable by as many people as possible: with a keyboard, a screen reader or a switch, with larger text, with less motion, in light or dark. This page says what we aim for, what we have checked, what we know is not yet right, and how to tell us about a problem. Everything listed as done has been checked; anything we have not checked is listed as not checked.
The standard we aim for
We aim to meet the Web Content Accessibility Guidelines (WCAG 2.2) at level AA, on the website and, where those guidelines apply to an app, in the iPhone app. The website partly meets this standard: the known gaps are listed below. The app has not yet been assessed against it in full.
The website: what we have checked
- An automated check on every page. On a desktop-sized window, every page, in light and dark, with and without reduced motion, passes the WCAG 2.0, 2.1 and 2.2 level A and AA rules of axe-core, an open-source testing engine. On a 375 px touch screen it reported three items on two pages: one was real (the Nesteia name at the foot of each page was a small target) and has been fixed; the other two did not hold up when measured by hand. Where it could not work out the contrast of text for itself, we measured it.
- Keyboard. Every page can be used from the keyboard alone. We pressed Tab through every page from top to foot: each link, button and field is reached, each shows a clear focus ring, and nothing holds the focus.
- Skip link. The first Tab on every page is Skip to content, which moves you past the header to the page itself.
- Structure. Each page has one main heading, headings in order with no levels skipped, a header, a main area and a footer, labelled navigation, and its language set to British English, so a screen reader can move by heading or landmark.
- Colour contrast. Text meets the WCAG AA contrast ratios (4.5 to 1, or 3 to 1 for large text) in both light and dark. Where text sits on the drawn phones and badges, we measured it from screenshots.
- Not by colour alone. Links inside sentences are underlined. How strong the evidence for a stage is, is written as a word (High, Moderate and so on) beside its mark, and each stage in the phone's strip says whether it is passed, now or ahead.
- Text size. With the browser's text set to 20 or 24 px on a 375 px-wide screen, and at 320 px wide, no page scrolls sideways. With text at 200% on a desktop-sized window, or in a window 640 px wide, no page scrolls sideways either: long words, such as an email address, wrap instead.
- Touch. On a touch screen, everything you can press that is not a link inside a sentence is at least 44 px tall and 44 px wide: buttons, switches, chips, the header's and footer's links, the Nesteia name, the search field and everything in the drawn phone. Links inside running text are exempt under WCAG 2.5.8.
- Reduced motion. If your device asks for reduced motion, no animation runs on any page: sections appear in place, and the home page's phone changes without sliding. Its Play button still steps through a fast, one hour per second, and only when you press it.
- Light and dark. The site follows your device's appearance. The button in the header switches between light and dark, says which is on, and is remembered on your next visit.
- Images. Every photograph and screenshot has a text description. The badges drawn on the Strata page have names, such as "Clay, the 24 hour layer earned once". Decorative drawings are hidden from screen readers.
- The phone on the home page. Its timer, start time and End fast each open a sheet that behaves as a dialog: it takes the focus and is named by its title, the screen behind it cannot be reached, Tab stays inside it, Escape closes it from anywhere, and the focus goes back to what opened it.
- The phone on the Stages page is a picture of the app, so a screen reader skips it. The caption under it says the same thing in words, with the current and next stage as links.
The iPhone app: what the code and its tests show
Nesteia for iPhone is in testing on TestFlight. We list only what can be pointed to in the app's code, its automated tests or its recorded test notes.
- Larger text. Text uses the iPhone's own text styles, so it follows your chosen text size, and the large timer and badge sizes scale with it. Rows that would be cramped stack instead at the largest accessibility sizes. Today, Stages, History, Strata and Settings have been checked on the simulator at an accessibility text size about two and a half times the default, and the app's automated interface tests run Apple's accessibility audit for text size and cut-off text.
- VoiceOver. Buttons, timers, badges and charts carry spoken labels, and the automated audit checks that the elements on the screens it visits have descriptions, suitable roles and large enough hit areas. When a fast ends with VoiceOver on, the moment waits for a tap instead of moving on mid-sentence.
- Reduce Motion. The timer, the stage strip, the Stages screen, the fast-ended and past-goal moments, the badge unlock and the screening questions check Reduce Motion and fade instead of moving. The fast-ended moment has been seen doing so on the simulator.
- Dark mode. Every colour has a light and a dark value, and both are pinned by tests.
- Contrast. The colour pairs used for text are tested to meet the AA contrast ratio in light and dark, and the interface tests run Apple's contrast audit.
- Not by colour alone. A stage's evidence is given as a word and a filled circle, not a colour.
- Tap targets. The audit checks the hit area of everything on the screens it visits, and the moment at the end of a fast has a 44-point Continue button.
- No sound or video. The app plays no video or audio of its own, so captions and audio description do not arise.
Known issues
These are the gaps we know of today. Each has a fix planned; this page will change as they are made.
On the website
- The drawn phones are simulations of the app, built for the page. They behave like the app as far as we can make them, but they are not the app, and on the home page they are a demonstration rather than a way to do anything.
- Not yet tested with assistive technology. We have not yet used the site with a screen reader (VoiceOver on Mac or iPhone, NVDA, JAWS or TalkBack), with speech recognition, or with switch access.
- Browsers. The checks above were run in Chrome. We have not yet repeated them in Safari or Firefox, or on a real iPhone or Android phone.
In the iPhone app
- VoiceOver has not yet been walked end to end, on a real iPhone, through every common task: setting up, starting and ending a fast, logging, reading the stages and badges, and Settings. The automated audit covers the screens the interface tests visit, not every screen.
- Voice commands and switch access have not been tested.
- Reduce Motion has not yet been checked on onboarding, the timer style sheet, the log or the reflections, which animate without asking.
- Increase Contrast in iOS settings changes nothing in the app yet; its standard colours are what the contrast tests cover.
- The widgets and the Live Activity have not been through the accessibility audit.
- The app has been checked on the iPhone simulator; checks on a real iPhone are still to come.
Tell us about a problem
If something on the website or in the app is hard to use, or you need what is on a page in another form, email serhatdereli@icloud.com. Say which page or screen, what you were trying to do, and what you use to browse (for example, a screen reader, or your text size). We aim to reply within five working days. Nesteia is made by one person, Serhat Dereli, a sole trader trading as Nesteia, Bromley, UK.
How this statement was prepared
This is a self-assessment, made on 24 September 2026 by the maker; no outside auditor has reviewed it. For the website, every page was loaded in Chrome through Playwright, a browser-automation tool, and checked with axe-core 4.13.0, then by script and by eye: the keyboard route through each page, touch-target sizes on a 375 px touch screen, text size and sideways scrolling at 20, 24 and 32 px, reduced motion, light and dark, and the dialogs in the home page's phone. For the app, we read the code and its automated tests, including the interface tests that run Apple's accessibility audit, and the notes from the simulator checks at large text sizes. We will review this statement whenever the site or the app changes in a way that affects it, and at least every six months.