Accessibility
Last updated
The short version
We want SlipAway to work for everyone, including people using a screen reader, a keyboard alone, magnification, or reduced motion. This page covers both the website and the iOS app. It says what we have actually checked, what we know is imperfect, and how to tell us when something does not work.
What we aim for
We aim to meet WCAG 2.1 Level AA on the website, and Apple’s accessibility guidance in the app. We describe both as partially conformant: much of the standard is met, neither has had a full independent audit, and we are not claiming more than we can show.
What we have checked on this website
- The page declares its language, so screen readers pronounce it correctly.
- Headings run in order without skipped levels, so the page can be navigated by heading rather than read top to bottom.
- Decorative images carry empty alternative text, so they are skipped rather than announced as meaningless filenames.
- Every form field has a label that assistive technology can read. Placeholder text alone is not treated as a label, because it disappears as soon as you type.
- Keyboard focus is visible. You can see where you are while tabbing.
- Animation is disabled for anyone whose system requests reduced motion.
- Pinch-to-zoom is not blocked, so text can be enlarged on a phone.
- The site follows your system’s light or dark appearance rather than forcing one.
What we know is imperfect on the website
Listing these is the point of the page. If we only listed what works, this would be marketing rather than an accessibility statement.
- No independent audit. The checks above are our own. We have not had this site tested by an accessibility specialist or by users of assistive technology.
- No skip-to-content link. The page is short and has little repeated navigation, so the cost is small, but keyboard users cannot jump straight to the main content.
- Colour contrast has not been formally measured across every element in both light and dark appearance.
The SlipAway app
The app is built with SwiftUI and inherits a great deal from iOS itself. The specifics below come from reviewing our own code, not from a formal audit.
What works
- VoiceOver: controls carry explicit labels, hints, and traits where the visual design alone would not be enough — for example icon-only buttons.
- Most text scales with your Dynamic Type setting, because it uses the system’s semantic text styles rather than fixed sizes.
- Reduced motion is respected. Loading animations stop when your system asks for less movement.
- Large tap targets. The caller picker and the main actions use full-width rows, so selecting one does not require precise aiming — the app is designed to be used one-handed, without looking, sometimes under a table.
- No time limit on setting up a call. Nothing expires while you are reading or choosing.
What is imperfect
- It is an audio-first product, and that is a real limit. The point of SlipAway is a phone that rings audibly and a voice that talks back. If you are deaf or hard of hearing, the ringing screen and the on-screen call still work as a visible excuse to step away, but the part that makes the call convincing to people around you is sound you may not hear. We would rather say that plainly than imply the product serves everyone equally.
- Around two dozen pieces of text use a fixed size and do not grow with Dynamic Type. Most of the app does scale; these specific labels do not, and at the largest accessibility text sizes they will look out of place.
- The app is dark-only. It does not follow your system’s light appearance. This was a design decision for a product used at night; it is not the right answer for everyone, and we are reconsidering it.
- Very little haptic feedback. For an app whose main output is sound, vibration should carry more of the signal than it currently does.
- No formal VoiceOver testing. The labels are there because we wrote them, not because someone who relies on VoiceOver has run through the app end to end.
Telling us about a problem
If any part of the site or the app is difficult or impossible to use, please tell us — a specific report (“the call screen’s End button is unlabelled in VoiceOver”) helps far more than a general one, but send whatever you have.
We aim to reply within five working days. If we cannot fix something quickly, we will tell you what the workaround is and when we expect a proper fix.
How this statement was prepared
Prepared on 31 July 2026 by self-evaluation, covering both surfaces: a review of this site’s markup and styles against WCAG 2.1 Level AA, and a review of the iOS app’s source for Dynamic Type, VoiceOver labelling, reduced motion, and appearance handling.
Two problems found on the website during that review — missing visible focus indicators, and form fields relying on placeholder text instead of labels — were fixed before this page was published, rather than listed here as known issues. The app issues above are listed rather than fixed because they need design decisions and real testing, not a one-line change, and we would rather publish them than wait.